Re: [WIP PATCH] Manual rename correction

[Jeff King <peff@peff.net>]

On Wed, Aug 01, 2012 at 01:34:23PM +0700, Nguyen Thai Ngoc Duy wrote:

> On Wed, Aug 1, 2012 at 1:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> >
> >> Yes. This is probably cosmetics only, but without path information, we
> >> leave it to chance to decide which A to pair with B and C (in the
> >> A->B, A->C case above). Wrong path might lead to funny effects (i'm
> >> thinking of git log --follow).
> >
> > Isn't that why <A,B> and <A,C> can have different scores per object
> > name pair?  And if you mean by B and C the paths not object names,
> > and the blob at B and C are indeed identical, why would it matter?
> 
> I don't see how scores affect that. Suppose I have two trees and a
> rename-cache file:
> 
> $ git ls-tree -r HEAD^
> 100644 blob d00491    path1/foo
> 100644 blob d00491    path2/bar
> $ git ls-tree -r HEAD
> 100644 blob 0cfbf0    path1/fooo
> 100644 blob 00750e    path2/barr
> $ cat rename-cache
> d00491 0cfbf0 <score 1>
> d00491 00750e <score 2>
> 
> How can I be sure "git diff HEAD^!" will rename path1/foo =>
> path1/fooo and path2/bar => path2/barr, not path1/foo => path2/barr
> and path2/bar => path1/fooo?

You can't. A pathless mapping can never represent that. I think my (and
Junio's argument) is more like: why would you care? And that gets back
to the statement I just made elsewhere in the thread. Which is that you
need to consider the purpose of the rename detection. For generating
diffs and for merging, it doesn't matter in the above case. If the point
is to communicate some semantics of the change (e.g., if your change was
"double the final letter of each filename, and also make a small change),
then that is what the commit message is for.

-Peff