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

[skillzero@gmail.com]

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

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