threads / discuss / 9692

Mixing cherry-pick and merge

Subject: Mixing cherry-pick and merge

## tl;dr

3 messages between Aug 29, 2007 and Aug 29, 2007.

replies: 2people: 3as markdown or json

Michel Marti· Aug 29, 2007, 12:05 UTC · lore

I just merged from a branch from which I previously cherry-picked some commits and now the log contains the already cherry-picked commits twice (which is rather confusing). Is this a bug or a feature?

Steps to reproduce:

mkdir foo && cd foo git init echo 123 >file git add file git commit -m "init" git checkout -b branch echo 321 >file git commit -a -m "commit from branch" => Created commit 531fa08: commit from branch git checkout master git cherry-pick 531fa08 git merge branch git-log --pretty=oneline e5e8011c1ab7c9b8509604d27327b29fd1f7003a Merge branch 'branch' ad91b39e433228809eb3cd6281cb686bf4871da0 commit from branch 531fa081d93249288efb70e9e8204e4ed9d70099 commit from branch bc0a5bca29620eccd5b75e473d102317d8ce29f7 init

Karl Hasselström· Aug 29, 2007, 13:14 UTC · re: Michel Marti · lore

Re: Mixing cherry-pick and merge

On 2007-08-29 14:05:55 +0200, Michel Marti wrote:

> I just merged from a branch from which I previously cherry-picked
> some commits and now the log contains the already cherry-picked
> commits twice (which is rather confusing). Is this a bug or a
> feature?

It's an inevitable consequence of git's design. When you cherry-pick a commit, you create a (maybe slightly modified) copy of it with different ancestry. If you then merge a branch that contains the original commit, you will get both the original and the copy as ancestors of your new merge commit.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Johannes Schindelin· Aug 29, 2007, 13:22 UTC · re: Karl Hasselström · lore

Re: Mixing cherry-pick and merge

Hi,

On Wed, 29 Aug 2007, Karl Hasselstr?m wrote:

Show 11 quoted lines

> On 2007-08-29 14:05:55 +0200, Michel Marti wrote:
> 
> > I just merged from a branch from which I previously cherry-picked some 
> > commits and now the log contains the already cherry-picked commits 
> > twice (which is rather confusing). Is this a bug or a feature?
> 
> It's an inevitable consequence of git's design. When you cherry-pick a 
> commit, you create a (maybe slightly modified) copy of it with different 
> ancestry. If you then merge a branch that contains the original commit, 
> you will get both the original and the copy as ancestors of your new 
> merge commit.

I guess that people are not even aware that they can rebase with Git. Sounds like a perfect use case to me.

Ciao, Dscho