RE: [PATCH 1/3] t3030: fix accidental success in symlink rename
> > 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.
Show 5 quoted lines
> > 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.
Show 14 quoted lines
> 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.
I completely agree, keeping the symlink would be the right thing to do. When I worked on the patch which added that test, my only concern was eliminating the rename/add conflict on "e" (which seemed pointless, since the content of "e" was identical in both branches).
--Ken Schalk