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

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Jan 14, 2009, 07:34 UTC
Message-ID: <496D9572.2090303@viscovery.net>
In-Reply-To: <2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com>

skillzero@gmail.com schrieb:

Show 6 quoted lines

> Is there any way to apply a commit to 2 different branches (which have
> diverged) in a way that git will remember so that when the 2 branches
> merge later, it won't result in duplicate commits? I find that I often
> make changes that days or weeks later find out that some other branch
> needs that change and by then, there have been lots of commits to both
> branches after the commit I want.

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 you don't have the slight suspicion, then you have to take the second-best route, namely to cherry-pick the commit onto a branch just like in 1. above, and continue with 2. and 3. In this case you have the commit twice, but not more than that.

-- Hannes