git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Mar 25, 2011, 17:51 UTC
Message-ID
<20110325175124.GA24513@sigill.intra.peff.net>
In-Reply-To
<7v1v1v6qs2.fsf@alter.siamese.dyndns.org>
On Fri, Mar 25, 2011 at 10:42:05AM -0700, Junio C Hamano wrote:
Show 10 quoted lines
> 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.

Show 15 quoted lines
> > 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
Previous: Junio C HamanoNext: Schalk, Ken
Message 8 of 14 in “merge recursive and code movement”
  1. Jay SoffianMar 24, 2011
  2. Jeff KingMar 25, 2011
  3. Jeff KingMar 25, 2011
  4. Jeff KingMar 25, 2011
  5. Jeff KingMar 25, 2011
  6. 1/3 t3030: fix accidental success in symlink renameJeff King, Mar 25, 2011
  7. Junio C HamanoMar 25, 2011
  8. Jeff KingMar 25, 2011
  9. Schalk, KenMar 25, 2011
  10. 2/3 merge: handle renames with replacement contentJeff King, Mar 25, 2011
  11. 3/3 merge: turn on rewrite detectionJeff King, Mar 25, 2011
  12. Jay SoffianMar 25, 2011
  13. Techlive ZhengJul 16, 2012
  14. Jeff KingJul 16, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.