skillzero@xxxxxxxxx wrote: > 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). > -- No, if you use merges it will not duplicate. It will know exactly what to do because it is the same commit in all branches. Only git-cherry-pick will duplicate the same patch, but as a different new commit. Then when merging the merge sees a merge conflict but since it is exactly the same change it will accept it. The same happens if two different patches have exact same hunk, the merge is smart to accept the same change from two sources. What happen with cherry-pick is that all the hunks match. Boaz -- 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
