threads / discuss / 2114

What's in git.git repository

Subject: What's in git.git repository

## tl;dr

4 messages between Oct 15, 2005 and Oct 16, 2005.

replies: 3people: 2as markdown or json

Junio C Hamano· Oct 15, 2005, 05:48 UTC · lore

The "master" branch has been updated with some "obviously correct" updates, as usual.

In proposed updates, there are currently two topics.

One is the new tag dereference notation and showing the deref'ed tag from the remote side via ls-remote I posted last night.

I'd have this graduate to the "master" branch after some more testing, only if people are interested in it; otherwise I'm thinking about dropping this (I am not particularly interested in this enhancement myself).

Another is the improved handling of funny characters in pathnames. The final notation follows what Paul Eggert outlined in his message a couple of days ago -- C-style quoted string enclosed in a pair of double-quotes. I have not written formal set of tests, but updated git-diff-*, git-ls-files, git-ls-tree, and git-apply seem to do the right thing with my limited hand-tests.

Sven Verdoolaege· Oct 15, 2005, 10:03 UTC · re: Junio C Hamano · lore

Re: What's in git.git repository

On Fri, Oct 14, 2005 at 10:48:35PM -0700, Junio C Hamano wrote:

> I'd have this graduate to the "master" branch after some more
> testing, only if people are interested in it; otherwise I'm
> thinking about dropping this (I am not particularly interested
> in this enhancement myself).

Dereferencing of tags to trees could be interesting for tools such as dirdiff. Of course, you can always do the dereferencing yourself and I'm planning on rewriting it in C anyway.

skimo

Junio C Hamano· Oct 15, 2005, 23:48 UTC · lore

Re: What's in git.git repository

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

Show 11 quoted lines

>> I'd have this graduate to the "master" branch after some more
>> testing, only if people are interested in it; otherwise I'm
>> thinking about dropping this (I am not particularly interested
>> in this enhancement myself).
>
> Fair enough -- it simplifies (and speeds up) the git-findtags script I
> posted. Actually, it makes it redundant. But if it's not
> elegant/needed/wanted in the C core, git-findtags can deal with it in
> the soft and sloppy sphere of perl scripts.
> Most people don't need this at all, and I guess that's why we managed
> so long without it. But I think it's a basic plumbing service.

Oh, I did not mean that I did not *like* the implementation or feature. I just was unsure if that was what you and Pasky would find useful.

I was trying to add something that would be useful in general, but if what I did was missing the mark and wasn't something you two found useful, there was no need to add it.

So, thanks for the feedback and background rationale. Let's have it in "master" then.

Junio C Hamano· Oct 16, 2005, 02:20 UTC · lore

Re: What's in git.git repository

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.