Re: A bug in git merge

[Jeff King <peff@peff.net>]

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