A bug in git merge

A bug in git merge

[Orgad Shaneh]

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

Re: A bug in git merge

[Jeff King]

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

> 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