On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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). -- 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
