I have a C codebase which supports a number of build personalities, for a given board architecture. It's mostly in maintenance mode. We don't do new active development on it.
We have a new board for a generation 2 of the product. Generation 2 will replace generation 1 (we aren't making any more Gen 1 boards). Generation 2 will require a good chunk of the code to be rewritten completely. I'd say 50% of it. OTOH, there is some code that will just stay the same. Making the build modular to support both types isn't worth it to us. So we're essentially going to permanently fork the project into two.
I'm soliciting input on whether to just
- Make a new git repository, copy the code from the old into it and take off and see where the future takes us.
- Keep the same repository, but just add more branches.
We currently use a scheme in our repository of having a
master branch for production releases, a
testing branch where we accumulate "blessed" work, and individual branches for different units of work we do.
The Pros/Cons as I see them are:
- Two Repositories
- Pros: Branches stay simple. Forced to have a repository for each loaded if I need to compare
- Cons: Can't cherry pick between the two (we rarely do this though)
- One Repository, Different Branches
- Pros: Code all stays in same branch, maybe able to leverage some "cross branch" features of git
- Cons: Have to annotate the
testingbranches for the two different things to disambiguate them
Which should we do, and why?