Re: A bug in git merge

From: Jeff King <peff@peff.net>
Date: Mar 27, 2018, 12:49 UTC
Message-ID: <20180327124942.GA18448@sigill.intra.peff.net>
In-Reply-To: <CAGHpTBJ-4a5+5=303_N-n3TtUg_sXt6J1cad0WCQ4Kc-=HDdSA@mail.gmail.com>

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