From: Junio C Hamano <junkio@cox.net>
Date: Sun, 16 Oct 2005 02:20:10 GMT
Subject: Re: What's in git.git repository
Message-ID: <7vpsq6fbj9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46a038f90510151734k141f218crc2ccfbb78769e518@mail.gmail.com>

Martin Langhoff <martin.langhoff@gmail.com> writes:

> One thought I had this morning is that given that the
> tree->commit->tagobj relation is unique and stable, it'd be a valid
> strategy to have files in .git/refs/tags/ optionally contain the 3
> identifiers. It is plainly safe to cache this permamently, the only
> pain now is to deal with teaching all the porcelains about it.
>
> What do you think?

Many ref readers read just the first 40 bytes and ignore the
rest, so storing "tag-SHA1 followed by optional information"
there would not hurt them that much.  But the question now is
what optional information to place there?

Obviously, we could do:

        echo '5dc01c59... tree=c39ae07f...' >.git/refs/tags/v2.6.11
        echo '26791a8b... commit=9ee1c9... tree=e4660ac...' >.git/refs/tags/v2.6.12
	echo '0918385d... blob=b92c9c0...' >.git/refs/tags/junio-gpg-pub

But, then we could also do:

	(
        	echo '5dc01c59...'
                git-cat-file tag v2.6.11
	) >.git/refs/tags/v2.6.11

There is no need to read 'tag' object separately -- it is all
there.  The same thing can be said for a tag that refers to
another tag that refers to a commit that contains a tree.  So
the question becomes "where to stop?".

I suspect the answer to that question is "it depends".  And I
also suspect "sed -e '...' <.git/refs/tags/v2.6.11" after we add
minimum optional information (not tag text but only commit and
perhaps tree object name) to these files would not be that much
cheaper than doing "git-cat-file commit v2.6.11 | sed -e '...'".
In other words, my gut feeling tells me that it would not buy us
that much.

I've also thought about showing v2.6.12^{tree} in addition to
v2.6.12^{} from ls-remote, and showing v2.6.12^{commit} instead
of v2.6.12^{}, to make the type of what it dereferences to more
explicit.  I did not do things that way because I was not quite
sure how much the additional complexity and additional output
from ls-remote would buy us.