We are a small development shop. We are starting a brand-new Linux-only
project in Git, and we only have experience of one year and one large
project with Git. My boss is the lead on this project and is accustomed to
command-line CVS. Because our projects are very large and complex and we
have so few developers, we tend to KISS in the extreme. Requirements: a
central repository, minimize merging and branching. This project: a Linux
driver for a large chip. We get periodic SDK drop-offs from the chip people
and we do extensive modifications, sometimes specific to a single customer,
that we develop. So the problem is, how to setup the project so that we can
most easily merge in these occasional SDK changes into our tree.
It seems to me that the obvious strategy is to have a trunk of our code and
a branch of the chip SDK, which gets updated and then merged into our
trunk. later we may need customer branches as well.
Is this strategy worth considering:
two trees of code, one for the chip maker's SDK, and one our trunk of
development. The SDK could be a submodule? That way the developer could
easily see the original SDK side-by-side in his desktop with the
development tree, and use non-Git tools to compare and bring in new files
and do "git add" instead of trying to learn how to use the merging tools.
I realize this is awkward and un-Gitly but we have a big job, few people,
little time, and we absolutely can't be sloppy or uncontrolled. Any
thoughts other than RTFM which I am doing?
Thanks for any advice....
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.