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. 

or

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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to