From: skillzero@gmail.com Date: Wed, 14 Jan 2009 08:08:06 GMT Subject: Re: git merge and cherry-pick and duplicated commits? Message-ID: <2729632a0901140008r59e429aeq3ce367e1bc7df71@mail.gmail.com> In-Reply-To: <496D9572.2090303@viscovery.net> On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt wrote: > Well, the way to do it is "careful planning". > > If you have a *slight* suspicion that some change *might* be needed on a > different branch, then: > > 1. you commit the change on a branch of its own that forks off of the > merge-base of *all* the branches that *might* need it; > > 2. next, you merge this fix-up branch into the branch where you need it > first, which is very likely your current topic-under-development. > > 3. Later you can merge the branch into the other branches if you find that > it is really needed. If I create a separate bug-fix-only branch X that forks from the latest common commit of all the branches that might need it and some of those branches already have commits after that merge base (e.g. branch Z is 5 commits after the common merge base by the time I fix the bug), will git be able to merge the new branch X into Z in a way that will allow me to also merge branch X into my original feature branch A and then later merge A into Z without duplicating the commit that is now in both branch X and Z? It seems like I'd run into my original duplicate commit problem because even though branch X was originally based off the same parent commit, it will have a different parent when it is merged into Z because Z is no longer at that common merge commit (it's 5 commits beyond it).