On Wed, Dec 20, 2017 at 3:43 AM, Andreas Krey <a.krey@xxxxxx> wrote:
> Hi everybody,
>
> we just stumbled over a situation in which a merge commits
> staged changes into the merge commit. This happens when the
> merged-in branch does have commits ('main') but has the same
> tree ('--allow-empty') as the merge base:
>
> git init
> echo eins >a
> git add a
> git commit -m initial
> git branch sub
> git commit -m main --allow-empty
> git checkout sub
> : two
> echo zwei >>a
> git add a
> git commit -m underway
> : three
> echo drei >>a
> git add a # important
> git status
> git diff --cached
> git merge master -m 'merge'
> git status
> git log --cc -1
>
> If the change isn't staged (comment out the '# important' line)
> the change survives as unstaged.
>
> That is a bug?
Yes, it's definitely a bug; thanks for reporting it. We have a
specific set of tests for this type of situation in t6044, which was
intended to test all the merge strategies and ensure they didn't have
this class of bug. It turns out that there is an additional codepath
within one of the strategies that wasn't tested, and which you've
tripped over. I've got some patches to fix this up that I'll respond
with shortly.
