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

From: skillzero@gmail.com <skillzero@gmail.com>
Date: Jan 14, 2009, 06:21 UTC
Message-ID: <2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com>
In-Reply-To: <5EA96780-EF4C-4B31-9C60-6ABAF21663FA@silverinsanity.com>

On Tue, Jan 13, 2009 at 9:31 PM, Brian Gernhardt <benji@silverinsanity.com> wrote:

Show 9 quoted lines

> After the cherry-picks, the repo looks like this:
>
> o-o-A'-B' (master)
>  \
>  o-A-B-o (branch:2daf23)
>
> A and A' are different commits.  Same with B and B'.  If you check the SHA1
> of master at this point, it will NOT be 702fd... (B).  Cherry pick creates a
> new commit that (as far as git is concerned) is totally unrelated.

That's what I was somewhat disappointed by. Even though the result of the commit had a different hash, I assumed git would keep some kind of internal per-commit hash so it could tell later that two commits were the same and not re-apply them.

> The simplest method is to rebase branch after doing the cherry-picks.  This
> should only be done if your branch has not been published.

The problem is, by the time I wanted to do the cherry-pick, I had already committed other stuff to the branch. I tried doing 'git rebase master branch' when on master and it just applied all the stuff from master to branch.

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.