What's in git.git repository

What's in git.git repository

[Junio C Hamano]

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.

Re: What's in git.git repository

[Sven Verdoolaege]

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

Re: What's in git.git repository

[Junio C Hamano]

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

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

Re: What's in git.git repository

[Junio C Hamano]

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.