For me its not really clear whether your developers work on a project and do changes on the SDK from the chip guys, or the project is purely (extensive) modifications to the SDK?
In both cases, I think you can do both the options you proposed like this: Create a git repository that has 2 submodules. Those 2 submodules point to a different branch on the same repository. The first is the SDK as received from the chip guys (for example named 'original') The second is the same SDK but with the modifications of your developers. (for example named 'develop') When a new version is received from the chip guys, apply it to the first submodule. Commit and push. Now go to the second submodule. To there do git pull origin develop. Of course a developer who really doesnt want to do the (relatively trivial) merge part of the changes of the chip-guys with git, he can view the changes of the SDK from 'original' and apply them manually to the 'develop' branch. But I would not recommend it. Moreover, developers already have to have pull (which is essentially merge) experience, to merge changes from other developers. That is a consequence of being with multiple developers. On Tuesday, March 26, 2013 6:59:54 PM UTC+1, John Fisher wrote: > > 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.
