On Fri, Mar 25, 2011 at 10:42:05AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html