Re: [WIP PATCH] Manual rename correction

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 1, 2012, 06:09 UTC
Message-ID: <7v4nongn3e.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8AYzYTJ+k72ZEuWW-RdKe7arYbbscVALNYakKSfYqD_zw@mail.gmail.com>

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?

Show 6 quoted lines

>>> 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.