Re: git merge and cherry-pick and duplicated commits?

[skillzero@gmail.com]

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