A bug in git merge

Orgad Shaneh· Mar 27, 2018, 09:53 UTC · lore

Hi,

If I cherry-pick a commit that added a line, then merge another commit which removes this line, the line remains in the file instead of being removed.

The following script demonstrates the bug.

file should be equivalent on both branches

git init seq 1 20 > file git add file git commit -m 'Initial' sed -i "s/^5/5\n55/" file git commit -a -m 'Added 55' git checkout -b other HEAD^ git cherry-pick master git commit --amend --author 'Author <a@b.c>' --no-edit # generate a new hash sed -i '/55/d' file git commit -a -m 'Removed 55' git checkout master git merge --no-edit other git diff other # Should be equal

- Orgad

Jeff King· Mar 27, 2018, 12:49 UTC · re: Orgad Shaneh · lore

Re: A bug in git merge

On Tue, Mar 27, 2018 at 12:53:52PM +0300, Orgad Shaneh wrote:

Show 22 quoted lines

> If I cherry-pick a commit that added a line, then merge another commit
> which removes this line, the line remains in the file instead of being
> removed.
> 
> The following script demonstrates the bug.
> 
> file should be equivalent on both branches
> 
> git init
> seq 1 20 > file
> git add file
> git commit -m 'Initial'
> sed -i "s/^5/5\n55/" file
> git commit -a -m 'Added 55'
> git checkout -b other HEAD^
> git cherry-pick master
> git commit --amend --author 'Author <a@b.c>' --no-edit # generate a new hash
> sed -i '/55/d' file
> git commit -a -m 'Removed 55'
> git checkout master
> git merge --no-edit other
> git diff other # Should be equal

This isn't a bug; it's the expected behavior for a 3-way merge.

The merge looks only at the two final states to be merged, and the merge base. The three states we have are:

    base: without line 55
    ours: with line 55
  theirs: without line 55

And since only one side made a change, the resolution is to take the change in the final result. The fact that the other branch actually manipulated the file (and how it manipulated it) isn't considered at all.

The fact that it was a cherry-pick doesn't change that. A cherry-pick is an application of the same changes, but it has no history-relationship with the original commit in Git.

One could argue for or against the user experience of history as a DAG, 3-way endpoint merges, and how cherry-picks are stored, but this is all working according to Git's design and not a bug.

-Peff