Cogito: cg-clone doesn't like packed tag objects

Cogito: cg-clone doesn't like packed tag objects

[H. Peter Anvin]

Packed tag objects breaks Cogito when using git+ssh:// transport.

Example:

cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git

	-hpa

Re: Cogito: cg-clone doesn't like packed tag objects

[Petr Baudis]

Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Packed tag objects breaks Cogito when using git+ssh:// transport.
> 
> Example:
> 
> cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git

I changed the code to use the git-*-fetch tools to fetch the objects
referenced by tags, so this works properly now. Thanks for the report.

It takes loooong time, unfortunately - scp -r takes its time itself on
many small files, and then we have to make a separate call to
git-ssh-fetch for each tag. Isn't that braindamaged... :/

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Cogito: cg-clone doesn't like packed tag objects

[H. Peter Anvin]

Petr Baudis wrote:
> 
> It takes loooong time, unfortunately - scp -r takes its time itself on
> many small files, and then we have to make a separate call to
> git-ssh-fetch for each tag. Isn't that braindamaged... :/
> 

Perhaps git-ssh-fetch should be fixed?  :)

	-hpa

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> It takes loooong time, unfortunately - scp -r takes its time itself on
> many small files, and then we have to make a separate call to
> git-ssh-fetch for each tag. Isn't that braindamaged... :/

I think you could run git-peek-remote to find all the refs and
then run git-fetch-pack to slurp all the tags (and heads for
that matter) at once.  Is there a particular reason you would
prefer the commit walker?

Re: Cogito: cg-clone doesn't like packed tag objects

[Petr Baudis]

Dear diary, on Sat, Sep 24, 2005 at 04:00:04AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> > It takes loooong time, unfortunately - scp -r takes its time itself on
> > many small files, and then we have to make a separate call to
> > git-ssh-fetch for each tag. Isn't that braindamaged... :/
> 
> I think you could run git-peek-remote to find all the refs and
> then run git-fetch-pack to slurp all the tags (and heads for
> that matter) at once.  Is there a particular reason you would
> prefer the commit walker?

Actually, probably not, except consistency with rsync and http handling
- but that's obviously not too good reason. I did it this way since I'm
going to be a bit busy again from now on.

I will probably rewrite the tags fetching to use git-peek-remote
(info/refs for http) the next weekend. One problem with this is that in
many repositories, git-update-server-info does not get ever run and
things would break "mysteriously". I don't want the policy that the user
has to take care of this on his own for Cogito, so I will probably add
something that will automagically append git-update-server-info at least
to the post-update hook (like

	uphook="$_git/hooks/update-post"
	if ! [ -x "$uphook" ]; then
		if ! [ -e "$uphook" ]; then
			echo '#!/bin/sh' >>"$uphook"
			echo 'exec git-update-server-info' >>"$uphook"
		fi
		# If the user added something custom and left the hook
		# disabled, he knew what he was doing. Also don't
		# reenable the hook if we already did that once.
		if [[ "$(grep -v '^#\($\|[^#]\)\|^$' "$uphook")" == "*exec git-update-server-info*" ]]; then
			chmod a+x "$uphook"
			echo "## Enabled by Cogito. It won't try to enable it again as long as this comment is here." >>"$uphook"
		fi
	fi

or something).

Actually, I might also add something like

	[ -e "$_git/git-dummy-support" ] && git-update-server-info

at all the places in Cogito where I update the refs. Then the
default post-update hook could change to

	[ -e "$_git/git-dummy-support" ] && exec git-update-server-info

and be enabled by default?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Cogito: cg-clone doesn't like packed tag objects

[Daniel Barkalow]

On Sat, 24 Sep 2005, Petr Baudis wrote:

> Dear diary, on Sat, Sep 24, 2005 at 04:00:04AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
> > Petr Baudis <pasky@suse.cz> writes:
> > 
> > > It takes loooong time, unfortunately - scp -r takes its time itself on
> > > many small files, and then we have to make a separate call to
> > > git-ssh-fetch for each tag. Isn't that braindamaged... :/
> > 
> > I think you could run git-peek-remote to find all the refs and
> > then run git-fetch-pack to slurp all the tags (and heads for
> > that matter) at once.  Is there a particular reason you would
> > prefer the commit walker?
> 
> Actually, probably not, except consistency with rsync and http handling
> - but that's obviously not too good reason. I did it this way since I'm
> going to be a bit busy again from now on.

It wouldn't actually be very hard to rewrite git-*-fetch programs to fetch 
with a bunch of starting points. The main reason I haven't is actually 
that I don't have any ideas for a way to extend the command line argument 
format to include it.

	-Daniel
*This .sig left intentionally blank*

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>> I think you could run git-peek-remote to find all the refs and
>> then run git-fetch-pack to slurp all the tags (and heads for
>> that matter) at once.  Is there a particular reason you would
>> prefer the commit walker?
>
> Actually, probably not, except consistency with rsync and http handling
> - but that's obviously not too good reason.

We would end up doing things internally differently between
git-native (fetch/clone-pack) and other protocols (commit walker
which is git-aware, and rsync which is not) anyway.

I misspoke for 'git-fetch-pack' in the above -- git-fetch-pack
without any refspec fetches all the refs, so you do not need a
separate peek-remote.  Right now 'git fetch' wrapper does not
let you take advantage of this, but if we wanted to add '--all'
flag to 'git fetch' wrapper, it can be implemented very easily
and efficiently for the git-native protocol.  An implementation
of such a flag for other protocols would use git-ls-remote to
find out the refs upfront.

> I will probably rewrite the tags fetching to use git-peek-remote
> (info/refs for http) the next weekend.

If you are targetting multiple protocols, git-ls-remote is the
one to use, not peek-remote.  It internally uses peek-remote for
git-native protocol, and emulates it using info/refs for http
and recursive get for rsync, so no new coding on Cogito part
should be necessary.

> default post-update hook could change to
>
> 	[ -e "$_git/git-dummy-support" ] && exec git-update-server-info
>
> and be enabled by default?

That is a thought.  While I think doing update-server-info
everywhere whenever you update ref is going a bit overboard, I
agree there should be an easy way for the end user to keep
repositories that are public accessible all times.  But running
server-info upon every commit does not make much sense to me --
something is seriously broken if we need to do that.

Cases when you would want to make your repository accessible
from outside itself varies and preferred transport obviously
depends on it.

 - Your private working area.  Typically does not allow
   anonymous downloads.  You are the only one to use git tools
   and compilation there (that's what 'private' means).

 - A CVS style shared repository.  May allow anonymous
   downloads, and allow uploads to people with 'commit
   privilege' in CVS lingo.

 - A public distribution point, like kernel.org repository.
   This is just a special case of the 'shared repository' above,
   with yourself as the only uploader.

I thought there would be more classes, but it really boils down
to whether you would allow anonymous downloads or not -- so
let's call them private and public.

Fetching over non git-native protocol is the only case where
server-info matters; so obviously it is nicer if public
repository is arranged so that update-server-info is run
everytime refs and set of packs change.

I do not think of a good reason not to use git-aware protocol
when one is fetching from a private repo -- so if we just say
people should not use non git-aware protocol when doing so, we
do not have to do server-info in the private repositories at
all.

So the question is, how often do we need to run update to keep
the refs and set of packs in public repository in sync with the
server-info.  What do people do in public repository to affect
set of packs and the refs?

 - Initiate a push into it from somewhere else; this case is
   covered by enabling post-update hook.

 - You log on to the machine of public repository and run 'git
   repack'; this runs update-server-info, so it is OK.

 - You log on to the machine of public repository and run fetch
   of another repository -- you may even end up hand merging and
   creating new commits.

 - You log on to the machine of public repository and do your
   development, making your own commits.

It is the latter two cases where your 'update-server-info
everywhere in Cogito' would be needed -- but is it realistic?

Re: Cogito: cg-clone doesn't like packed tag objects

[Petr Baudis]

Dear diary, on Sat, Sep 24, 2005 at 08:10:40PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> > default post-update hook could change to
> >
> > 	[ -e "$_git/git-dummy-support" ] && exec git-update-server-info
> >
> > and be enabled by default?
> 
> That is a thought.  While I think doing update-server-info
> everywhere whenever you update ref is going a bit overboard, I
> agree there should be an easy way for the end user to keep
> repositories that are public accessible all times.  But running
> server-info upon every commit does not make much sense to me --
> something is seriously broken if we need to do that.

Point taken, you are right.

BTW, Cogito has for a while the command 'cg-admin-setuprepo' which is
designed to be used to create those public accessible repositories where
you typically only push to. Recently, I've also changed it so that it
just enables the default post-update hook; is it safe to assume that the
default template post-update hook shipped with GIT will be
good-to-be-autoenabled on public repositories and will always contain
the git-update-server-info invocation (unless it becomes irrelevant in
the future) ?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> ...; is it safe to assume that the
> default template post-update hook shipped with GIT will be
> good-to-be-autoenabled on public repositories 

I do not think that is an unreasonable assumption.  After all,
sample hooks are there to help people setting up common usage
patterns, not to show off flashy but irrelevant-to-the-real-world-needs
features ;-).

Please yell loudly when somebody posts a patch or brings up a
proposal to break that assumption in the future.

Re: Cogito: cg-clone doesn't like packed tag objects

[Nick Hengeveld]

On Wed, Nov 09, 2005 at 03:14:21PM -0800, Junio C Hamano wrote:

> > ...; is it safe to assume that the
> > default template post-update hook shipped with GIT will be
> > good-to-be-autoenabled on public repositories 
> 
> Please yell loudly when somebody posts a patch or brings up a
> proposal to break that assumption in the future.

Wouldn't this be a problem on public repositories that are hosted with
DAV?

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.

Re: Cogito: cg-clone doesn't like packed tag objects

[Petr Baudis]

Dear diary, on Thu, Nov 10, 2005 at 12:36:14AM CET, I got a letter
where Nick Hengeveld <nickh@reactrix.com> said that...
> Wouldn't this be a problem on public repositories that are hosted with
> DAV?

Hmm. Yes, that's bad. Couldn't the HTTP pusher actually get the current
server info, update it at the pusher's side and send it back?

And add a warning to some documentation that HTTP push won't trigger the
update hooks.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Cogito: cg-clone doesn't like packed tag objects

[Nick Hengeveld]

On Thu, Nov 10, 2005 at 12:44:05AM +0100, Petr Baudis wrote:

> Hmm. Yes, that's bad. Couldn't the HTTP pusher actually get the current
> server info, update it at the pusher's side and send it back?

Yes, although duplicating all of what update-server-info does is going
to take a while...

However, the only thing of interest to update-server-info that http-push
is able to change is a ref.  It would be much more straightforward to
lock and update info/refs after a successful push; is that good enough?
The same thing could apply to objects/info/packs if/when http-push
starts sending packs.

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Nick Hengeveld <nickh@reactrix.com> writes:

> On Wed, Nov 09, 2005 at 03:14:21PM -0800, Junio C Hamano wrote:
>
>> > ...; is it safe to assume that the
>> > default template post-update hook shipped with GIT will be
>> > good-to-be-autoenabled on public repositories 
>> 
>> Please yell loudly when somebody posts a patch or brings up a
>> proposal to break that assumption in the future.
>
> Wouldn't this be a problem on public repositories that are hosted with
> DAV?

Not unless you arrange the DAV server to honor hooks. ;-).

IOW, yeah, there may be problems.

Re: Cogito: cg-clone doesn't like packed tag objects

[Petr Baudis]

Dear diary, on Sat, Sep 24, 2005 at 03:18:33AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> told me that...
> Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter
> where "H. Peter Anvin" <hpa@zytor.com> told me that...
> > Packed tag objects breaks Cogito when using git+ssh:// transport.
> > 
> > Example:
> > 
> > cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git
> 
> I changed the code to use the git-*-fetch tools to fetch the objects
> referenced by tags, so this works properly now. Thanks for the report.

And now thanks to "walt" I realized that this is a completely wrong way
to go. The problem is that the tags don't have to tag anything on your
branch, and if you are fetching a given branch, you want only commits
from that branch. But fetching the tags will cause all the commits
connected to the tags getting slurped too, and we didn't want that.

So the strategy I'm thinking of now is to manually (I think no GIT tool
can do that for me) dereference the possible tag chain until I end up at
some non-tag object. Now, if it is a commit and I don't have it yet, it
means that it is not interesting to me because it does not belong to a
branch I'm following, so I will just ignore the tag (won't download
anything else and won't record it in the refs/tags directory).

If it's NOT a commit, well, that's a question.  On the assumption that
it won't be a great deal of data and it's likely to be assumed that we
have it, I would be inclined to fetching it, but I don't feel strongly
about it.

The ideal and the least expensive solution for this, obviously, would be
having this logic in git-fetch-pack. :-)

Opinions?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Cogito: cg-clone doesn't like packed tag objects

[Brian Gerst]

Petr Baudis wrote:
> Dear diary, on Sat, Sep 24, 2005 at 03:18:33AM CEST, I got a letter
> where Petr Baudis <pasky@suse.cz> told me that...
> 
>>Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter
>>where "H. Peter Anvin" <hpa@zytor.com> told me that...
>>
>>>Packed tag objects breaks Cogito when using git+ssh:// transport.
>>>
>>>Example:
>>>
>>>cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git
>>
>>I changed the code to use the git-*-fetch tools to fetch the objects
>>referenced by tags, so this works properly now. Thanks for the report.
> 
> 
> And now thanks to "walt" I realized that this is a completely wrong way
> to go. The problem is that the tags don't have to tag anything on your
> branch, and if you are fetching a given branch, you want only commits
> from that branch. But fetching the tags will cause all the commits
> connected to the tags getting slurped too, and we didn't want that.
> 
> So the strategy I'm thinking of now is to manually (I think no GIT tool
> can do that for me) dereference the possible tag chain until I end up at
> some non-tag object. Now, if it is a commit and I don't have it yet, it
> means that it is not interesting to me because it does not belong to a
> branch I'm following, so I will just ignore the tag (won't download
> anything else and won't record it in the refs/tags directory).

I think this is the right idea.

> If it's NOT a commit, well, that's a question.  On the assumption that
> it won't be a great deal of data and it's likely to be assumed that we
> have it, I would be inclined to fetching it, but I don't feel strongly
> about it.

It could point to a tree (ie. the kernel's v2.6.11 tag), which may end 
up being a large pull.  I think it's best to not care what type of 
object the tag references.

--
				Brian Gerst

Re: Cogito: cg-clone doesn't like packed tag objects

[Petr Baudis]

Dear diary, on Mon, Sep 26, 2005 at 11:55:34PM CEST, I got a letter
where Brian Gerst <bgerst@didntduck.org> told me that...
> Petr Baudis wrote:
> >If it's NOT a commit, well, that's a question.  On the assumption that
> >it won't be a great deal of data and it's likely to be assumed that we
> >have it, I would be inclined to fetching it, but I don't feel strongly
> >about it.
> 
> It could point to a tree (ie. the kernel's v2.6.11 tag), which may end 
> up being a large pull.  I think it's best to not care what type of 
> object the tag references.

Yes, but the object may not be reachable in any other way.

Simple question - if you have a tagged blob containing a GPG public key
(let's call it.. hmm.. e.g. junio-gpg-pub ;), would you expect Cogito to
ignore it or pick it up?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Opinions?

I do not understand this part of your logic:

> .... But fetching the tags will cause all the commits
> connected to the tags getting slurped too, and we didn't want that.

What is the objective here?  If you fetch a tag without the
object being tagged (or commit without its tree), you will end
up with smaller object database but you would get yelled at by
git-fsck-objects.

Re: Cogito: cg-clone doesn't like packed tag objects

[Petr Baudis]

Dear diary, on Tue, Sep 27, 2005 at 12:23:41AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
> > .... But fetching the tags will cause all the commits
> > connected to the tags getting slurped too, and we didn't want that.
> 
> What is the objective here?  If you fetch a tag without the
> object being tagged (or commit without its tree), you will end
> up with smaller object database but you would get yelled at by
> git-fsck-objects.

Yes - so you can't save the tag objects either, but then you'll re-slurp
them again and again, which is kind of silly. Alternatively, you could
actually make git-fsck-object silent about the case when an unreachable
(not referenced in refs/) tag object references a non-existing object -
perhaps unless --strict is passed to it. If you think the rest of my
logic is ok, I think this change to facilitate this "tags caching" is
not unreasonable.

The alternative solution would be to have the tags cache with the tag
objects separate of the main object database, but that'd be very dirty.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Yes - so you can't save the tag objects either, but then
> you'll re-slurp them again and again, which is kind of
> silly. Alternatively, you could actually make git-fsck-object
> silent about the case when an unreachable (not referenced in
> refs/) tag object references a non-existing object - perhaps
> unless --strict is passed to it. If you think the rest of my
> logic is ok, I think this change to facilitate this "tags
> caching" is not unreasonable.

Now you completely lost me.  I really do not understand what you
mean by tags caching and re-slurping.

If your user _is_ interested in the tag, say v0.99.7d, wouldn't
it make sense to make sure that, after the user fetches the tag,
the user can build v0.99.7d point release as well?  What do you
think the reason is when your user says he is interested in
another tag, junio-gpg-pub?  Wouldn't it be the most natural
interpretation that he wants to get the blob the tag refers to,
so that he can use it with git-verify-tag?  What good does it do
for the user if you get only the tag object and do not get the
blob the tag refers to?  Yes, he can say "git cat-file tag
junio-gpg-pub", but that by itself is not that interesting if it
cannot be used to validate the other tags (or itself).

If the users ask for a tag, I think it is easier for them to
understand if you made sure you give them the complete set of
objects that need to support that tag, at least by default.
Giving the user an option to override it to make a sparse,
incomplete, fsck-unclean repository is fine as a spacesaver
option, but I think that should be left for "more advanced
users" who understand the ramification of using the option.

I happen to publish maint branch, but I could have done without.
I can make a temporary branch out of v0.99.7c tag, add fixes to
extend that branch, tag the branch head as v0.99.7d, and delete
the temporary branch without publishing it at all.

The tree needed to build v0.99.7d point release would be only
reachable by fetching that tag (and here, "fetching the tag"
really means "making sure the receiving repository has the tag
object, and all the objects that are reachable from that tag
object"), so "fetching only the tag object and not the object it
refers to" in that case does not make much sense for the end
user.  Yes, he can say "git cat-file tag v0.99.7d", but that by
itself is not that interesting if he cannot use it to build that
release.

Re: Cogito: cg-clone doesn't like packed tag objects

[Tom Prince]

Junio C Hamano <junkio@cox.net> writes:

> Petr Baudis <pasky@suse.cz> writes:
>
>> Yes - so you can't save the tag objects either, but then
>> you'll re-slurp them again and again, which is kind of
>> silly. Alternatively, you could actually make git-fsck-object
>> silent about the case when an unreachable (not referenced in
>> refs/) tag object references a non-existing object - perhaps
>> unless --strict is passed to it. If you think the rest of my
>> logic is ok, I think this change to facilitate this "tags
>> caching" is not unreasonable.
>
> Now you completely lost me.  I really do not understand what you
> mean by tags caching and re-slurping.
>

I think Petr is interested in the case where the user hasn't asked for a
particular tag. He wants to automatically grab all the tags in a repository,
or at least those that refer to a branch being downloaded.

Of course, if somebody asks for a specific tag, then everything necessary
should be downloaded. Somebody is fetching your maint branch, Petr want to
automatically download all the tags v0.99.7[a-d], without the user specifying
them explicitly. Or more complex, somebody is tracking your master but NOT
maint. Then Petr wants to download tags v0.99.[0-9] but not v0.99.7[a-d]. 

  Tom

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Tom Prince <tom.prince@ualberta.net> writes:

> Junio C Hamano <junkio@cox.net> writes:
>
>> Now you completely lost me.  I really do not understand what you
>> mean by tags caching and re-slurping.
>
> I think Petr is interested in the case where the user hasn't asked for a
> particular tag. He wants to automatically grab all the tags in a repository,
> or at least those that refer to a branch being downloaded.

Ah, _automatically_ was the key.

If all you had were tags and there were no branches (the "I
could have done without maint branch"), that kind of automatic
grabbing would not work well anyway.  I personally feel that is
a lost cause.  The user can run 'git ls-remote' himself to find
out if there are new tags on the remote side and ask for them if
needed.

Also, I feel names under refs/ is local to the repository, but
if the tags are automatically grabbed, I presume they are stored
directly under the same name in refs/tags as the remote side has
them?

Re: Cogito: cg-clone doesn't like packed tag objects

[Petr Baudis]

Dear diary, on Tue, Sep 27, 2005 at 07:28:16AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Tom Prince <tom.prince@ualberta.net> writes:
> 
> > Junio C Hamano <junkio@cox.net> writes:
> >
> >> Now you completely lost me.  I really do not understand what you
> >> mean by tags caching and re-slurping.
> >
> > I think Petr is interested in the case where the user hasn't asked for a
> > particular tag. He wants to automatically grab all the tags in a repository,
> > or at least those that refer to a branch being downloaded.
> 
> Ah, _automatically_ was the key.
> 
> If all you had were tags and there were no branches (the "I
> could have done without maint branch"), that kind of automatic
> grabbing would not work well anyway.

I don't think that's a realistic situation. IMHO it is a reasonable
requirement for Cogito fetch that you are primarily fetching a _head_.
Then, you also grab tags which are meaningful for that head - that's
what I want to do. If you want to also specifically grab some extra
tags, you should be able to tell cg-fetch about that too (cg-fetch -t
tagname) or something. Being able to do this, I'm inclined to agree that
we shouldn't grab even trees and blobs.

> I personally feel that is a lost cause.  The user can run 'git
> ls-remote' himself to find out if there are new tags on the remote
> side and ask for them if needed.

Yes, that's perhaps a fine solution for the core GIT plumbing, but in
Cogito, I _really_ want to have this working automagically.

> Also, I feel names under refs/ is local to the repository, but
> if the tags are automatically grabbed, I presume they are stored
> directly under the same name in refs/tags as the remote side has
> them?

Yes. And I certainly don't say that what Cogito does now is perfect, not
even that it's very good. But we (well, rather the users) certainly _do_
need some kind of automatic tags fetching - that's something that has to
Just Work (tm).

As I already said in the past (without much feedback, unfortunately), we
certainly need to distinguish between private tags (specific for given
repository) and public tags (should be propagated by fetching).

Another thing I proposed back then (I think it was in June) was having
the refs/tags directory further divised based on heads, so all tags for
head A would be in refs/tags/A/, etc. I didn't pursue this idea now
because it seemed that there would be way too many duplicate stuff in
refs/tags/ since most tags are likely to be shared across heads, but
perhaps it is the beast and cleanest solution after all.

Dear diary, on Tue, Sep 27, 2005 at 12:37:48AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I think there should be a way to say "I do not care if this
> repository does not have all the history back to root -- as long
> as I can operate on reasonably recent commits, do not complain
> about missing objects" to fsck-objects and various fetch
> engines.  We can cauterize commit history chain using the grafts
> file so that 'git log', 'git whatchanged', and 'gitk' would stop
> somewhere.  Commit walkers can help you, albeit somewhat
> differently, if you do not give -a flag to them.

Well, this wasn't something I had on my mind in this thread, but it is
actually what I want to do too (I have such a loooong TODO list). Sure,
you can workaround the problem with grafts, but I think that this hack
should be really used only in specific cases (like grafting big history
pack after importing the project to GIT, making it kind of optional
"addon", which is actually very nice). In the general case, I would much
more like if you could say "I want only commits to the depth of 5" or
even CVS-like "I want only the HEAD commit" (actually, I received some
patches to make Cogito support this, but I didn't yet get to have a look
at them). This shifts the policy decision from the repository owner to
the user, and makes it contignuous instead of fragmented to the points
when you have grafts.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Cogito: cg-clone doesn't like packed tag objects

[Josef Weidendorfer]

On Tuesday 27 September 2005 11:40, Petr Baudis wrote:
> Another thing I proposed back then (I think it was in June) was having
> the refs/tags directory further divised based on heads, so all tags for
> head A would be in refs/tags/A/, etc. I didn't pursue this idea now
> because it seemed that there would be way too many duplicate stuff in
> refs/tags/ since most tags are likely to be shared across heads, but
> perhaps it is the beast and cleanest solution after all.

The problem here is that currently there are no global, public branches.
And you should not mix private heads in refs/heads with global tags.
Perhaps interpret tag objects as global branch names, similar to
the "mixture" in .git/refs ?

Josef

Re: Cogito: cg-clone doesn't like packed tag objects

[Petr Baudis]

Dear diary, on Tue, Sep 27, 2005 at 12:14:31PM CEST, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...
> On Tuesday 27 September 2005 11:40, Petr Baudis wrote:
> > Another thing I proposed back then (I think it was in June) was having
> > the refs/tags directory further divised based on heads, so all tags for
> > head A would be in refs/tags/A/, etc. I didn't pursue this idea now
> > because it seemed that there would be way too many duplicate stuff in
> > refs/tags/ since most tags are likely to be shared across heads, but
> > perhaps it is the beast and cleanest solution after all.
> 
> The problem here is that currently there are no global, public branches.
> And you should not mix private heads in refs/heads with global tags.

But we don't need any global tags or heads. You just have some heads in
your refs/heads (it doesn't matter if they are public or remote, that's
a "social" issue what you tell people to fetch). And based on your heads
you have in your refs/heads, there would be directories in your
refs/tags/ corresponding to those.

If you fetch remote head, its local subdirectory in refs/tags/ is
populated with the new tags, and if you merge two heads, the public tags
are copied around. Then if you are resolving a tag, we should first look
at refs/tags/$(readlink HEAD)/tagname, and if it doesn't exist, we would
look at refs/tags/tagname (so if you wanted to reference a tag not in
your head, you'd have to use a "head/tag" form). Optionally, you could
also look for refs/tags/*/tagname and if it gives you a unique match,
use that - but I'm not sure how good idea this is since it already makes
the lookup way too heuristical.

> Perhaps interpret tag objects as global branch names, similar to
> the "mixture" in .git/refs ?

I don't understand.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Cogito: cg-clone doesn't like packed tag objects

[Josef Weidendorfer]

On Tuesday 27 September 2005 14:34, Petr Baudis wrote:
> But we don't need any global tags or heads. You just have some heads in
> your refs/heads (it doesn't matter if they are public or remote, that's
> a "social" issue what you tell people to fetch). And based on your heads
> you have in your refs/heads, there would be directories in your
> refs/tags/ corresponding to those.

Ah, ok.

Let me see if I understand:
1) These tags are bound to a head, and they have the invariant that they 
appear in the commit history of the head.
2) They are updated automatically.
3) When someone rebases a head, the bound tags should be synced to the
rebased head's history.
4) Tags can appear multiple times, if they happen to be in the commit
history of multiple heads?

How to make sure that the invariant mentioned in (1) always holds?

> If you fetch remote head, its local subdirectory in refs/tags/ is
> populated with the new tags, and if you merge two heads, the public tags
> are copied around.

Ok, this is the "automatically updated" feature I talked about above.
So missing here is:
- If you want to get rid of a head, the tags should be removed
- If a head is rebased, this has to be detected and the tags recreated,
possibly removing some

Probably there should be a "cg-tag --recover" to resync these volatile
tags with tag objects appearing in the histories of heads?

As for lightweight tags of remote repositories, you probably need some
space to recover them e.g. on a rebase or creation of a new head without
running git-ls-remote all the time.

> Then if you are resolving a tag, we should first look 
> at refs/tags/$(readlink HEAD)/tagname, and if it doesn't exist, we would
> look at refs/tags/tagname (so if you wanted to reference a tag not in
> your head, you'd have to use a "head/tag" form).

Sounds nice.

> > Perhaps interpret tag objects as global branch names, similar to
> > the "mixture" in .git/refs ?
>
> I don't understand.

Tag objects in a repository could be interpreted as branch names
for commits based on it. When creating a new branch point, I first
would put a tag object on this branch, thus renaming it.
I think this would be quite handy for navigation in histories.

Josef

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Yes, that's perhaps a fine solution for the core GIT plumbing, but in
> Cogito, I _really_ want to have this working automagically.

I agree that would be nice.  If you are only interested in tags
that refer to commits that anchor points in published branches,
maybe we should have something along the lines of info/refs to
help the downloaders?  Perhaps info/refs showing the SHA1 id of
the non-tag object each tag dereferences to in addition to the
current output?

This is a bit hard and needs some thinking to do cleanly,
because what is in info/refs is what is sent from the publisher
side over git-native protocol at the beginning of the handshake,
and it is not easy to add that to git-native protocol cleanly
and backward-compatibly (I think I know how without breaking
existing clients, but it is not clean).

Re: Cogito: cg-clone doesn't like packed tag objects

[Linus Torvalds]

On Tue, 27 Sep 2005, Junio C Hamano wrote:
> 
> This is a bit hard and needs some thinking to do cleanly,
> because what is in info/refs is what is sent from the publisher
> side over git-native protocol at the beginning of the handshake,
> and it is not easy to add that to git-native protocol cleanly
> and backward-compatibly (I think I know how without breaking
> existing clients, but it is not clean).

Argh.

"git-upload-pack" very much on purpose never sends partial object stores: 
it really doesn't want to send a tag-object for you to even _look_ at 
unless it also sends all the objects that you are missing that the tag 
refers to.

I'd really be much happier with the tag fetching being separate.

For example, making

	git fetch --tags <dest>

fetch all tags _and_ the objects that they depend on would seem a _lot_ 
more appropriate.

The thing is, tags really may be totally private. For example, it makes 
sense to fetch tags when you pull an official tree (ie my kernel tree, or 
your git tree), but it does NOT make sense for me to fetch tags 
(automatically or not) when I pull from a developers tree.

That's why git fetch doesn't get the tags by default. It's WRONG. 

But we could certainly make it _easier_ to get tags when you want them. 
"git-ls-remote" already helps you, and

	git-ls-remote ... | cut -f2 | grep '^refs/tags/'

completes the picture. No protocol changes necessary, just some added 
magic to git-fetch.sh.

Actually, here's a simple and stupid patch.

Untested as usual, but hey, how hard can it be?

		Linus

----
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -5,6 +5,7 @@
 _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
 _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
 
+tags=
 append=
 force=
 update_head_ok=
@@ -17,6 +18,9 @@ do
 	-f|--f|--fo|--for|--forc|--force)
 		force=t
 		;;
+	--tags)
+		tags=t
+		;;
 	-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\
 	--update-he|--update-hea|--update-head|--update-head-|\
 	--update-head-o|--update-head-ok)
@@ -151,7 +155,12 @@ case "$update_head_ok" in
 	;;
 esac
 
-for ref in $(get_remote_refs_for_fetch "$@")
+taglist=
+if [ "$tags" ]; then
+	taglist=$(git-ls-remote "$remote" | awk '/refs\/tags/ { print $2":"$2 }')
+fi
+
+for ref in $(get_remote_refs_for_fetch "$@" $taglist)
 do
     refs="$refs $ref"
 

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Tue, 27 Sep 2005, Junio C Hamano wrote:
>> 
>> This is a bit hard and needs some thinking to do cleanly,
>> because what is in info/refs is what is sent from the publisher
>> side over git-native protocol at the beginning of the handshake,
>> and it is not easy to add that to git-native protocol cleanly
>> and backward-compatibly (I think I know how without breaking
>> existing clients, but it is not clean).
>
> Argh.
>
> "git-upload-pack" very much on purpose never sends partial object stores: 
> it really doesn't want to send a tag-object for you to even _look_ at 
> unless it also sends all the objects that you are missing that the tag 
> refers to.
>
> I'd really be much happier with the tag fetching being separate.

What Pasky wants to do, which I misunderstood first and gave
essentially the same response to, is to help this senario:

    User tracks git.git#master and nothing else, i.e. she pulls
    from my master branch from time to time.  The tool notices
    that I tagged a commit on the master branch (not necessarily
    the tip at the time of pulling) with v0.99.8 tag, which she
    has not have, and fetches v0.99.8 tag and stores it under
    .git/refs/.  Currently Cogito does not let her specify
    where on the receiving end to place that tag and always
    places it in .git/refs/tags/v0.99.8, but that can be fixed
    later.

The current ls-remote (or underlying fetch-pack protocol) does
not help this because the SHA1 given to Cogito is the object
name of the tag, and without fetching the tag object and looking
at what it refers to, Pasky cannot say "Oh, this new v0.99.8 tag
is the commit on the branch being tracked".

The protocol extension I had in mind, which I said is not clean,
is from upload_pack(), in addition to the existing send_ref()
call which sends "object-name refname" list like this:

4899334e96a076bb8780968c5075b214aa80fab9	HEAD
d5bc7eecbbb0b9f6122708bf5cd62f78ebdaafd8	refs/heads/maint
3cc35e29ec252d0dca1139106fbaa70cb9ad6ef1	refs/heads/master
4899334e96a076bb8780968c5075b214aa80fab9	refs/heads/pu
348c4c66dacb1810a9bcd592e72f98a465233488	refs/heads/rc
0918385dbd9656cab0d1d81ba7453d49bbc16250	refs/tags/junio-gpg-pub
d6602ec5194c87b0fc87103ca4d67251c76f233a	refs/tags/v0.99
f25a265a342aed6041ab0cc484224d9ca54b6f41	refs/tags/v0.99.1
...

we could send phony entries like this:

b92c9c07fe2d0d89c4f692573583c4753b5355d2	deref/tags/junio-gpg-pub
a3eb250f996bf5e12376ec88622c4ccaabf20ea8	deref/tags/v0.99
78d9d414123ad6f4f522ffecbcd9e4a7562948fd	deref/tags/v0.99.1

These phony entries tell the receiver what the tags eventually
resolve to.  Pasky could use this to see if he has the named
object from the usual fetch path, and if he finds matches,
ask git-fetch-pack to get them.

We would need to teach git-clone and git-fetch to ignore deref/
if they do not already do so.

Re: Cogito: cg-clone doesn't like packed tag objects

[Linus Torvalds]

On Tue, 27 Sep 2005, Junio C Hamano wrote:
> 
> The protocol extension I had in mind, which I said is not clean,
> is from upload_pack(), in addition to the existing send_ref()
> call which sends "object-name refname" list like this:
> 
> 4899334e96a076bb8780968c5075b214aa80fab9	HEAD
...
> 
> we could send phony entries like this:
> 
> b92c9c07fe2d0d89c4f692573583c4753b5355d2	deref/tags/junio-gpg-pub
> a3eb250f996bf5e12376ec88622c4ccaabf20ea8	deref/tags/v0.99
> 78d9d414123ad6f4f522ffecbcd9e4a7562948fd	deref/tags/v0.99.1

Yes, it would work, but I really think that there's no downside to just 
having a

	git fetch --tags <dest>

since that's just a few lines of trivial code, with no special cases.

Otherwise:

> We would need to teach git-clone and git-fetch to ignore deref/
> if they do not already do so.

in general, it's just a really ugly special case, I think.

		Linus

Re: Cogito: cg-clone doesn't like packed tag objects

[Linus Torvalds]

On Tue, 27 Sep 2005, Linus Torvalds wrote:
> 
> Yes, it would work, but I really think that there's no downside to just 
> having a
> 
> 	git fetch --tags <dest>
> 
> since that's just a few lines of trivial code, with no special cases.

Btw, there are upsides too. Remember how confused people were about your
very own v0.99.7a-d releases? They are _not_ on your main path, so those
tags wouldn't have been picked up even if Petr did his "pick up tags to
stuff you merge automatically" thing.

In fact, if you'd add "--tags" as some kind of automated flag in the
.git/remote/ file, then doing a "git fetch origin" could automatically 
fetch tags by default, _without_ having the mistake of fetching them in 
general (it probably _does_ make sense to track tags from the origin, 
since you get the ones the origin had at "clone" time anyway).

		Linus

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Yes, it would work, but I really think that there's no downside to just 
> having a
>
> 	git fetch --tags <dest>
>
> since that's just a few lines of trivial code, with no special cases.

I do not oppose that idea.  I was just trying to point out that
'git fetch --tags' does not solve what Pasky wants to do -- in
his ideal world, people track branches, and tags that refer to
objects that are on those tracked branches are automatically
fetched; at the same time tags irrelevant to the tracked
branches are not fetched at all.  'git fetch --tags' would
require the user to slurp in objects on branches she is not
interested in.

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

>> we could send phony entries like this:
>> 
>> b92c9c07fe2d0d89c4f692573583c4753b5355d2	deref/tags/junio-gpg-pub
>> a3eb250f996bf5e12376ec88622c4ccaabf20ea8	deref/tags/v0.99
>> 78d9d414123ad6f4f522ffecbcd9e4a7562948fd	deref/tags/v0.99.1
>
> Yes, it would work,..
> in general, it's just a really ugly special case, I think.

I think we could do this instead, to make it less ugly.

b92c9c07fe2d0d89c4f692573583c4753b5355d2	refs/tags/junio-gpg-pub!*
a3eb250f996bf5e12376ec88622c4ccaabf20ea8	refs/tags/v0.99^0

I am not sure what the syntax should be, but the idea is to
express the "refname" side using "extended SHA1" syntax.  In the
above example, I added a postfix '!*' to mean "deref tag
zero-or-more times until you get a non-tag" ('!' to mean deref
tag once and complain if the object is not tag, '!!' is deref
twice, '!!!' is to deref three times and so on).  It might be
better to spell "v0.99^0" as "v0.99!*" in this context. [*1*]

Both git-clone-pack and git-fetch-pack need to be told to ignore
funny tagnames with trailing '!*', otherwise they would ask for
the pointed-at object (which is not harmful but redundant) and
the clone would create "refs/tags/v0.99!*", a file with a funny
name.  Git-peek-remote should report that, and server-info.c
should be told to prepare these extra entries for ls-remote over
other protocols.

But I tend to agree that this is really a special case needed to
support the "tagged objects are automatically followed by tags
that tag them" model, and not needed if we stay in "tag is just
a ref, and a ref is just an object name, and asking for an
object pulls in other objects that are reachable from them"
model.  So it is not a very high priority for me, but I think
this is one way to help Cogito cleanly, and I am willing to see
how much damage this would cause to other parts of the core, *if*
Cogito wants to use this mechanism.

The alternative would be what Pasky outlined in his message --
bypassing git transport layer to fetch single object by hand,
repeatedly dereferencing it until he gets a non-tag.  I think
that is unnecessary misery for him.


[Footnote]

*1* The difference from '^0' is that '!' does not complain on
non-commit, and can be used to peel the onion one layer at a
time.  I do not know how useful the latter is in practice but
somebody may want to express chains of trust by signing tags.

Peeling the onion

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Linus Torvalds <torvalds@osdl.org> writes:
>
>>> we could send phony entries like this:
>>> 
>>> b92c9c07fe2d0d89c4f692573583c4753b5355d2	deref/tags/junio-gpg-pub
>>> a3eb250f996bf5e12376ec88622c4ccaabf20ea8	deref/tags/v0.99
>>> 78d9d414123ad6f4f522ffecbcd9e4a7562948fd	deref/tags/v0.99.1
>>
>> Yes, it would work,..
>> in general, it's just a really ugly special case, I think.
>
> I think we could do this instead, to make it less ugly.
>
> ...
>
> The alternative would be what Pasky outlined in his message --
> bypassing git transport layer to fetch single object by hand,
> repeatedly dereferencing it until he gets a non-tag.  I think
> that is unnecessary misery for him.

I did not hear much from the people involved since this message,
but I have a bit less ugly solution along the lines outlined
above, in the proposed updates branch.  Incidentally this would
also simplify Martin's git-findtags, especially if we do not
worry about its '-t' option.

I'll be sending 3-patch series; the first two are preparatory
but what may be useful for Pasky and Martin is in the third
one.

    [PATCH] Ignore funny refname sent from remote.
    [PATCH] Introduce notation "ref^{type}".
    [PATCH] Show peeled onion from upload-pack and server-info.

Re: Peeling the onion

[Junio C Hamano]

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

> I personally don't care much for the -t option, at the moment. I do
> think that tree identity is in some contexts more important than
> commit identity, so there will be instances where you really want to
> have a canonical way to "drill down" to the tree.

I do not know how useful it would be, but the onion peeler can
be told to dereference commit to tree.

$ ./git-cat-file -s 'v0.99.8^{tree}' 
6875
$ ./git-cat-file -s 'v0.99.8^{commit}' 
435
$ ./git-cat-file -t 'v0.99.8^{tree}' 
tree
$ ./git-cat-file -t 'v0.99.8^{commit}' 
commit
$ ./git-rev-parse v0.99.8 \
  v0.99.8^0 v0.99.8^{commit} \
  v0.99.8^{commit}^{tree} v0.99.8^{tree}
b041895af323bdef10cc9a718bda468ba3622bc0
91dd674e30ba0298e89c9be2657024805170c2ac
91dd674e30ba0298e89c9be2657024805170c2ac
bfd844a69bfd582d107622c27b89e9b959e89fd8
bfd844a69bfd582d107622c27b89e9b959e89fd8

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Petr Baudis <pasky@suse.cz> writes:
>
>> Opinions?
>
> I do not understand this part of your logic:
>
>> .... But fetching the tags will cause all the commits
>> connected to the tags getting slurped too, and we didn't want that.
>
> What is the objective here?  If you fetch a tag without the
> object being tagged (or commit without its tree), you will end
> up with smaller object database but you would get yelled at by
> git-fsck-objects.

Having said that, I am sympathetic to what you are trying to do
here; if what I understand what you are trying to do matches
what you are actually trying to do, that is.

I think there should be a way to say "I do not care if this
repository does not have all the history back to root -- as long
as I can operate on reasonably recent commits, do not complain
about missing objects" to fsck-objects and various fetch
engines.  We can cauterize commit history chain using the grafts
file so that 'git log', 'git whatchanged', and 'gitk' would stop
somewhere.  Commit walkers can help you, albeit somewhat
differently, if you do not give -a flag to them.

Re: Cogito: cg-clone doesn't like packed tag objects

[Sven Verdoolaege]

On Mon, Sep 26, 2005 at 11:25:36PM +0200, Petr Baudis wrote:
> So the strategy I'm thinking of now is to manually (I think no GIT tool
> can do that for me) dereference the possible tag chain until I end up at
> some non-tag object. 

If it _is_ a commit, you could use 
git-rev-list --max-count=1 $tag

It won't help you though if it isn't.

skimo

Re: Cogito: cg-clone doesn't like packed tag objects

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

Petr Baudis wrote:
> So the strategy I'm thinking of now is to manually (I think no GIT tool
> can do that for me) dereference the possible tag chain until I end up at
> some non-tag object. Now, if it is a commit and I don't have it yet, it
> means that it is not interesting to me because it does not belong to a
> branch I'm following, so I will just ignore the tag (won't download
> anything else and won't record it in the refs/tags directory).

git-rev-parse $tagname^0


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: Cogito: cg-clone doesn't like packed tag objects

[Linus Torvalds]

On Tue, 27 Sep 2005, Ryan Anderson wrote:
> 
> git-rev-parse $tagname^0

You need "--verify". Otherwise git-rev-parse will think that you just have 
a strange filename or other random thing:

	prompt$ git-rev-parse 000^0
	000^0

	prompt$ git-rev-parse --verify 000^0
	fatal: Needed a single revision

Now, if the tag doesn't point to a commit, then the "^0" thing will fail. 
What you could use instead is

	git-rev-list --max-count=1 "$tag"

since git-rev-list will actually follow the tag. Of course, whether it 
does so correctly or not if the tagged object doesn't exist, I dunno. 
Testing needed.

Finally, you might just do it by hand

	type=$(git-cat-file -t "$obj") || exit
	if [ "$type" == "$tag" ]; then
		tagged=$(git-cat-file tag "$obj" |
			sed 's/object // ; q')
		git-rev-parse --verify "$tagged"
	fi

untested, of course.

		Linus

Re: Cogito: cg-clone doesn't like packed tag objects

[Ryan Anderson]

On Tue, Sep 27, 2005 at 08:34:22AM -0700, Linus Torvalds wrote:
> On Tue, 27 Sep 2005, Ryan Anderson wrote:
> > 
> > git-rev-parse $tagname^0
> 
> You need "--verify". Otherwise git-rev-parse will think that you just have 
> a strange filename or other random thing:
> 
> 	prompt$ git-rev-parse 000^0
> 	000^0

Hmm:

$ cat .git/refs/tags/v2.6.13-rc4
7eab951de91d95875ba34ec4c599f37e1208db93
$ git-rev-parse v2.6.13-rc4
7eab951de91d95875ba34ec4c599f37e1208db93
$ git-rev-parse v2.6.13-rc4^0
63953523341bcafe5928bf6e99bffd7db94b471e
$ git-rev-parse 63953523341bcafe5928bf6e99bffd7db94b471e^0
63953523341bcafe5928bf6e99bffd7db94b471e

# The typo that demonstrates what you did:
$ git-rev-parse 7eab951de91d95875ba34ec4c599f37e1208db93^-
7eab951de91d95875ba34ec4c599f37e1208db93^-

$ git-rev-parse 7eab951de91d95875ba34ec4c599f37e1208db93^0
63953523341bcafe5928bf6e99bffd7db94b471e

So I think --verify is beneficial if you want errors returned, but if
you know you have real tags or commits, git-rev-parse without the
--verify seems to do the right thing.

Or, at the very least, in the case where I used this
(linux/scripts/setlocalversion), this behavior is fine.

-- 

Ryan Anderson
  sometimes Pug Majere

Re: Cogito: cg-clone doesn't like packed tag objects

[Linus Torvalds]

On Tue, 27 Sep 2005, Ryan Anderson wrote:
> 
> $ cat .git/refs/tags/v2.6.13-rc4
> 7eab951de91d95875ba34ec4c599f37e1208db93
> $ git-rev-parse v2.6.13-rc4
> 7eab951de91d95875ba34ec4c599f37e1208db93
> $ git-rev-parse v2.6.13-rc4^0
> 63953523341bcafe5928bf6e99bffd7db94b471e
> $ git-rev-parse 63953523341bcafe5928bf6e99bffd7db94b471e^0
> 63953523341bcafe5928bf6e99bffd7db94b471e

The point being that if you want to test whether you have the thing the 
tag _points_ to, you should verify it.

And that's where the "--verify" flag comes in:

	[torvalds@g5 linux]$ git-rev-parse v2.6.11^0 ; echo $?
	error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
	v2.6.11^0
	0

and if the object the tag points to didn't exist at _all_ in your object
store, you'd have silently gotten

	[torvalds@g5 linux]$ git-rev-parse v2.6.11^0 ; echo $?
        v2.6.11^0
        0

but if you used "--verify", you'd have at least gotten

	[torvalds@g5 linux]$ git-rev-parse --verify v2.6.11^0 ; echo $?
	fatal: Needed a single revision
	1

which is what you want, I thought.

		Linus

Re: Cogito: cg-clone doesn't like packed tag objects

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> If it's NOT a commit, well, that's a question.  On the assumption that
> it won't be a great deal of data and it's likely to be assumed that we
> have it, I would be inclined to fetching it, but I don't feel strongly
> about it.

v2.6.11 tag is not a commit but presumably it would slurp in a
lot of data.