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

From: skillzero@gmail.com <skillzero@gmail.com>
Date: Jan 14, 2009, 08:08 UTC
Message-ID: <2729632a0901140008r59e429aeq3ce367e1bc7df71@mail.gmail.com>
In-Reply-To: <496D9572.2090303@viscovery.net>

On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:

Show 13 quoted lines

> 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).