Re: [PATCH 1/3] t3030: fix accidental success in symlink rename

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> In this test, we have merge two branches. On one branch, we
> renamed "a" to "e". On the other, we renamed "a" to "e" and
> then added a symlink pointing at "a" pointing to "e".

I read this five times but still couldn't figure out that you meant that
the other side 'added a symlink "a" to allow people keep referring to "e"
with the old name "a"' until I actually read the actual test you are
describing here.

Besides, /we have merge/s/have//, I think.

> The results for the test indicate that the merge should
> succeed, but also that "a" should no longer exist. Since
> both sides renamed "a" to the same destination, we will end
> up comparing those destinations for content.
>
> But what about what's left? One side (the rename only),
> replaced "a" with nothing. The other side replaced it with a
> symlink. The common base must also be nothing, because any
> "a" before this was meaningless (it was totally unrelated
> content that ended up getting renamed).
>
> The only sensible resolution is to keep the symlink.

I agree.

We should treat structural changes and do a 3-way on that, and then
another 3-way on content changes, treating them as an independent thing.
One side has "create 'e' out of 'a', removing 'a'" and "_create_ 'a', that
is unrelated to the original 'a'", the other side has "create 'e' out of
'a', removing 'a'", so the end result should be that we do both,
i.e. "create 'e' out of 'a', removing 'a'" and "create 'a'".  At the
content level, the result in 'e' may have to be decided by 3-way.  The
result in 'a' should be a clean merge taken from the former "with b/c
link" branch, as this is not even a create (by the side that added a
backward compatibility symbolic link) vs a delete (by pure-rename side)
conflict.