Nguyen Thai Ngoc Duy [off-list ref] 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?
quoted
quoted
There's also the problem with transferring this information. With
git-notes I think I can transfer it (though not automatically). How do
we transfer sha1 map (that you mentioned in the commit generation mail
in this thread)?
I wasn't clear. This is about transferring info across repositories.
It is simple to define a portable format to record Jeff's rename
cache database (it could be a text blob full of "x40 x40 score"
lines), point such a blob with a special ref, and write a Porcelain
to transfer and merge across repositories, e.g.
git fetch $there refs/rename-cache
new=$(
(
git cat-file blob refs/rename-cache
git cat-file blob FETCH_HEAD
) | sort | uniq | git hash-object -w --stdin)
git update-ref refs/rename-cache $new
And as Jeff said, that is orthogonal to the issue of what is being
stored. The contents of refs/rename-cache blob could be compiled
into a binary form for quicker access at runtime in the Porcelain.
On Wed, Aug 1, 2012 at 1:09 PM, Junio C Hamano [off-list ref] wrote:
Nguyen Thai Ngoc Duy [off-list ref] writes:
quoted
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?
--
Duy
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 [off-list ref] wrote:
quoted
Nguyen Thai Ngoc Duy [off-list ref] writes:
quoted
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