On 2008-12-26, pggrd <git@xxxxxxxxxxx> wrote: > most of the code in the project is shared between the threads > in certain files there are different code parts to meet client requirements > but even those files share the rest of the code How different are the chunks of code per client? A few minor differences, or large chunks of code? > What I need to be able to do is: > - to get code for any thread I like at any time > - to be able to develop each thread separately > - to be able to merge certain changes from one thread to another, at the same > time without loosing the changes specific to the thread, > and keep track of merge history > With GIT strategy to treat content as a single unity - if > you will try to merge branches - everything will be merged > thus overwriting the changes that need to stay. But in the > example above, if I make a change in the shared code in > one thread, I need to be able to populate this change to > all the threads, but this change only. Seems largely the same as maintaining an older release and backporting changes from the main trunk to it (or sometimes the other direction), while keeping them distinct. Which happens all the time... However, a maint release eventually atrophies -- changes stop coming in, and eventually your last customer using it has upgraded and the branch becomes unused. You can't do that with your "client branch", so eventually this will start diverging further and further from the trunk. The way to mitigate that is to have your main trunk contain only the stuff that is common to *all* your clients, and let each client branch maintain differences from this. So in effect, those "topic branches" are never getting merged back to the mainline. When you make changes that should go to every client, you make them on the master and merge them into the "topic branch" (your client branch). When you want a commit from client A to be used for client B, you cherry-pick (cherry-pick from within gitk is pretty neat for occasional, manual, cherry picks). The only caveat I see is that once in a while you'll want to just rebase each client branch against the master just for sanity. This should be done on one repository, and be a coordinated thing so that all the developers who're working on that particular client branch can re-fetch. You might end up doing this once in a few months so it's not bad I guess. Sitaram PS: I think all this will work, but others with more experience need to weigh in... it's always a bad idea to ask questions during the holidays, you never know who's manning the support lines ;-) PPS: As Santi said in the other reply, you should also consider making these changes part of a single code base, with some sort of configuration deciding what actually gets done. Would be cleaner in the long run I guess... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
