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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
