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

Petr Baudis [off-list ref] 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).

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"
 

Linus Torvalds [off-list ref] writes:

On Tue, 27 Sep 2005, Junio C Hamano wrote:

quoted

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.

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

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