Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> 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?
>>> 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.
--
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