Re: What's in git.git repository

From: Junio C Hamano <junkio@cox.net>
Date: Oct 16, 2005, 02:20 UTC
Message-ID: <7vpsq6fbj9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46a038f90510151734k141f218crc2ccfbb78769e518@mail.gmail.com>

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

Show 7 quoted lines

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