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

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

Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter
where "H. Peter Anvin" [off-list ref] 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.

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

Dear diary, on Sat, Sep 24, 2005 at 03:18:33AM CEST, I got a letter
where Petr Baudis [off-list ref] told me that...

Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter
where "H. Peter Anvin" [off-list ref] told me that...

quoted

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.

Petr Baudis wrote:

Dear diary, on Sat, Sep 24, 2005 at 03:18:33AM CEST, I got a letter
where Petr Baudis [off-list ref] told me that...

quoted

Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter
where "H. Peter Anvin" [off-list ref] told me that...

quoted

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

Dear diary, on Mon, Sep 26, 2005 at 11:55:34PM CEST, I got a letter
where Brian Gerst [off-list ref] told me that...

Petr Baudis wrote:

quoted

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.

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

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

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

On Tue, Sep 27, 2005 at 08:34:22AM -0700, Linus Torvalds wrote:

On Tue, 27 Sep 2005, Ryan Anderson wrote:

quoted

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

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