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

[Jeff King <peff@peff.net>]

On Fri, Mar 25, 2011 at 10:42:05AM -0700, Junio C Hamano wrote:

> 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.

Hmph. I edited it to try to be more clear, and obviously left in a typo.
I clearly need to proofread more.

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

It was actually s/have merge/merge.  So what I intended to write was:

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

If that's not clear enough, then feel free to swap it out for something
better.

> > 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.

Good, I think we are on the same page. Hopefully you will find my 2/3
correct at least in spirit, then, if not implementation. :)

-Peff