Potential bug with octopus merges and symlinks

[Michael McClimon <michael@mcclimon.org>]

I am having a problem with octopus merges when symbolic links are involved.
I'm not completely convinced this is a bug in git, but I'm also not convinced
that it's _not_. (If it's not, my apologies; I often find it very hard to
track down the answers to complicated git questions on the internet.)

There is a minimal reproducer available at
https://github.com/mmcclimon/git-merge-problem-demo. Fetch all the branches
there. The main branch contains a directory (dir1) with a single file
(file.txt), plus a symlink (dir2), which links to dir1. branch1 replaces this
symlink with a copy of the files that were linked to. (This was accomplished
with: rm dir2; cp -r dir1 dir2.) branch2 and branch3 do not touch this
directory at all.

Merging these three branches fails:

$ git merge branch1 branch2 branch3
Fast-forwarding to: branch1
Trying simple merge with branch2
Simple merge did not work, trying automatic merge.
Trying simple merge with branch3
error: Entry 'dir2/file.txt' not uptodate. Cannot merge.
Merge with strategy octopus failed.

The order here matters! Here is every permutation (1 here is the symlink
change) to git merge; only the first two fail, all the others work.

1 2 3   FAIL
1 3 2   FAIL
2 1 3   PASS
2 3 1   PASS
3 1 2   PASS
3 2 1   PASS
1 2     PASS
2 1     PASS
2 3     PASS
3 2     PASS
1 3     PASS
3 1     PASS

I tracked this down as best I could (I am not a C programmer), by adding 
`set -x` to my copy of git-octopus-merge.sh. I determined that the line is
failing is toward the very bottom of the main loop there: 
    git read-tree -u -m --aggressive  $common $MRT $SHA1

I had a read of the index-format.txt and then the git read-tree docs, and I
confess that I don't _totally_ follow the latter. But, I wonder if maybe
--aggressive is perhaps not aggressive enough if the parts of the index that
store symbolic link data aren't taken into account, when it's changed between
two versions and the blobs involved aren't actually different.

I recognize that replacing a symlink with real files under the same name is a
weird thing to do, but this is a pared-down example of a thing that happens
occasionally at $work, where we regularly octopus-merge 15+ heads into
development branches. I would also be happy to know, if this isn't a bug, if
there's some other workaround! The only way I know to fix this case is to
merge the symlink change, then rebase all in-flight branches against it. That
is often extremely time-consuming and tedious, though, and requires a human to
be involved (all the other merging is done by CI.)

Thanks!
Michael


Please review the rest of the bug report below.
You can delete any lines you don't wish to share.

[System Info]
git version:
git version 2.34.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64
compiler info: clang: 13.0.0 (clang-1300.0.29.3)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]


-- 
Michael McClimon
michael@mcclimon.org