Re: [RFC/PATCH 4/4] inexact rename detection eye candy

From: Jeff King <peff@peff.net>
Date: Feb 20, 2011, 10:04 UTC
Message-ID: <20110220100424.GB988@sigill.intra.peff.net>
In-Reply-To: <AANLkTi=s6FxnYVv3UinV4Q+4C_9dX9rCLQQoCFD7kG9S@mail.gmail.com>

On Sat, Feb 19, 2011 at 11:29:33AM -0500, Martin Langhoff wrote:

Show 10 quoted lines

> On Sat, Feb 19, 2011 at 5:25 AM, Jeff King <peff@peff.net> wrote:
> > During a merge, we might spend many seconds doing inexact
> > rename detection. It's nice to let the user know that
> > something is actually happening.
> 
> Given that we're doing costly work, could the results of rename
> matching be recorded in a .git/MERGE_RENAMES file?
> 
> If that file's available, the simple merge-helper script I've
> described is possible...

Yeah we can if it's useful, but I'd rather see a prototype merge helper first. In particular, your merge helper seems like it would help in two situations:

  1. In a rename/rename conflict, you have X becoming Y on one branch
     and Z on the other. You want to say "X should have become Y", and
     then have it 3-way merge X, Y, and Z, storing the result under the
     name Y.

     For that do we actually want the rename list, or just the list of
     rename/rename conflicts?

  2. If git misses a rename, then by definition won't that rename not be
     in the MERGE_RENAMES list? I guess it may have picked up the rename
     on one half of history, and you could use that?

     I'm not quite clear on the exact usage.

So it makes sense to me to get a working merge helper that just uses "git diff" as appropriate to look up old renames, and then we'll know what information is required.

-Peff