Re: What's in git.git repository

Martin Langhoff [off-list ref] 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.