Pulling tags from git.git

Pulling tags from git.git

[David Ho]

Hi,

I have been trying to pull from the git repo via rsync. 
(rsync://rsync.kernel.org/pub/scm/git/git.git)  I got all the commits
up to today but the tags since my initial cloning are missing.

I tried git pull --tags, I still only have old tags.
I switched to using the git protocol but that failed too.

git ls-remotes --tags showed, as expected, all the tags up to 1.2.4.

Is there a switch I missed?

Regards,
David

Re: Pulling tags from git.git

[David Ho]

Okay sorry, git fetch --tags did the trick.

Just out of curiosity, should git pull --tags behave similarly since
the difference is git pull does a merge after a fetch?

David

On 3/6/06, David Ho <davidkwho@gmail.com> wrote:
> Hi,
>
> I have been trying to pull from the git repo via rsync.
> (rsync://rsync.kernel.org/pub/scm/git/git.git)  I got all the commits
> up to today but the tags since my initial cloning are missing.
>
> I tried git pull --tags, I still only have old tags.
> I switched to using the git protocol but that failed too.
>
> git ls-remotes --tags showed, as expected, all the tags up to 1.2.4.
>
> Is there a switch I missed?
>
> Regards,
> David
>

Re: Pulling tags from git.git

[Andreas Ericsson]

David Ho wrote:
> Okay sorry, git fetch --tags did the trick.
> 
> Just out of curiosity, should git pull --tags behave similarly since
> the difference is git pull does a merge after a fetch?
> 

With the git or git+ssh protocol, tags will be autofollowed when you do 
a pull (only signed tags, I think). The auto-following is done by 
detecting tags that are fetched, so when you did a pull using rsync the 
tags weren't auto-followed but you got all the commits. Next, when you 
changed protocol to git:// you already had all the commit objects, so 
there was nothing to auto-detect tags on. Since you're using git:// now 
it should work as advertised in the future though.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Pulling tags from git.git

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> With the git or git+ssh protocol, tags will be autofollowed
> when you do a pull (only signed tags, I think).  The
> auto-following is done by detecting tags that are fetched,

Ah, you are correct.  We do not follow lightweight tags; I am
not sure if we should.

We detect from ls-remote output if you have objects pointed by
remote tags (either signed or unsigned -- we cannot tell it from
ls-remote output) and fetch those tags that point at what we
have.

The auto following is done only when you are tracking remote
branches, BTW.  Promiscuous fetch for immediate merging does not
follow tags.

Totally untested, so if somebody is interested, please test it,
and if it works, sign it off and bounce it back to me ;-).

-- >8 --
[PATCH] make "git fetch" follow unannotated tags as well.

---
diff --git a/git-fetch.sh b/git-fetch.sh
index 0346d4a..90c8882 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -375,7 +375,7 @@ case "$no_tags$tags" in
 		# using local tracking branch.
 		taglist=$(IFS=" " &&
 		git-ls-remote $upload_pack --tags "$remote" |
-		sed -ne 's|^\([0-9a-f]*\)[ 	]\(refs/tags/.*\)^{}$|\1 \2|p' |
+		sed -e 's/\^{}$//' -e 's/	/ /' |
 		while read sha1 name
 		do
 			test -f "$GIT_DIR/$name" && continue
@@ -386,7 +386,8 @@ case "$no_tags$tags" in
 			git-cat-file -t "$sha1" >/dev/null 2>&1 || continue
 			echo >&2 "Auto-following $name"
 			echo ".${name}:${name}"
-		done)
+		done |
+		sort -u)
 	esac
 	case "$taglist" in
 	'') ;;

Re: Pulling tags from git.git

[Andreas Ericsson]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> 
>>With the git or git+ssh protocol, tags will be autofollowed
>>when you do a pull (only signed tags, I think).  The
>>auto-following is done by detecting tags that are fetched,
> 
> 
> Ah, you are correct.  We do not follow lightweight tags; I am
> not sure if we should.
> 

I'm fairly sure we shouldn't. The default update-hook prevents them (if 
enabled), and I can't for the life of me think of why anyone would want 
to distribute such tags.

OTOH, preventing unannotated tags from being pushed seems like a better 
way than to not have the ability to auto-follow those same tags. After 
all, it's better to discourage than to disallow.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Pulling tags from git.git

[A Large Angry SCM]

Andreas Ericsson wrote:
> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>>
>>
>>> With the git or git+ssh protocol, tags will be autofollowed
>>> when you do a pull (only signed tags, I think).  The
>>> auto-following is done by detecting tags that are fetched,
>>
>>
>> Ah, you are correct.  We do not follow lightweight tags; I am
>> not sure if we should.
>>
> 
> I'm fairly sure we shouldn't. The default update-hook prevents them (if 
> enabled), and I can't for the life of me think of why anyone would want 
> to distribute such tags.
> 
> OTOH, preventing unannotated tags from being pushed seems like a better 
> way than to not have the ability to auto-follow those same tags. After 
> all, it's better to discourage than to disallow.
> 

Before you do this, please explain why unannotated tags are not useful, 
and so should not be allowed to be pushed.

Re: Pulling tags from git.git

[Andreas Ericsson]

A Large Angry SCM wrote:
> Andreas Ericsson wrote:
> 
>> Junio C Hamano wrote:
>>
>>> Andreas Ericsson <ae@op5.se> writes:
>>>
>>>
>>>> With the git or git+ssh protocol, tags will be autofollowed
>>>> when you do a pull (only signed tags, I think).  The
>>>> auto-following is done by detecting tags that are fetched,
>>>
>>>
>>>
>>> Ah, you are correct.  We do not follow lightweight tags; I am
>>> not sure if we should.
>>>
>>
>> I'm fairly sure we shouldn't. The default update-hook prevents them 
>> (if enabled), and I can't for the life of me think of why anyone would 
>> want to distribute such tags.
>>
>> OTOH, preventing unannotated tags from being pushed seems like a 
>> better way than to not have the ability to auto-follow those same 
>> tags. After all, it's better to discourage than to disallow.
>>
> 
> Before you do this, please explain why unannotated tags are not useful, 
> and so should not be allowed to be pushed.


Imagine Linus, getting his "please pull" emails and doing so only to 
find dozens of temporary tags fetched by the pull. Junio's patch (if I 
read it correctly) unconditionally fetches *ALL* tags reachable from the 
top of the commit-chain, which means there is no longer any way to keep 
temporary tags in a repo from which someone else will pull.

I for one riddle my repos with temporary tags whenever I'm trying 
something I'm not so sure of, or find an interesting bug or a design 
decision I'm not 100% sure of. Perhaps I should rather do this with 
branches, but imo branches are for doing work, whereas tags just mark a 
spot in the development so I easily can find them with gitk or some such.

I may be biased by the way we do things at work. In our workflow, all 
tags meant to be distributed have a short note in them which explains 
the rationale of the tag. For example, new versions have a very brief 
changelog that sales-people get on email (a blessing, that, since we 
devs no longer have to update feature-lists and such).

Tags not meant to be distributed are unannotated, and unannotated tags 
are kept out of published repos which are always stored at a central 
server. Everybody synchronize to those central repos, so nobody pulls 
from each other. Perhaps this is how the kernel devs work too, but if it 
ever changes the update hook will no longer be able to safeguard from it 
and the, in my eyes, temporary tags will be distributed in a 
criss-crossing mesh so no-one will ever know where it came from or who 
created it or why. I.e. a Bad Thing.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Pulling tags from git.git

[David Ho]

Andreas,

After get it working, I did an experiment where I hard-resetted my
local repo to v1.2.3, git-pruned and removed the v1.2.4 tag.  A git
pull with the git protocol does indeed pick up the tag.

Thanks for explaining what's going on under the hood.  Everything now
makes sense to me!

David

On 3/7/06, Andreas Ericsson <ae@op5.se> wrote:
> With the git or git+ssh protocol, tags will be autofollowed when you do
> a pull (only signed tags, I think). The auto-following is done by
> detecting tags that are fetched, so when you did a pull using rsync the
> tags weren't auto-followed but you got all the commits. Next, when you
> changed protocol to git:// you already had all the commit objects, so
> there was nothing to auto-detect tags on. Since you're using git:// now
> it should work as advertised in the future though.

Re: Pulling tags from git.git

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> Imagine Linus, getting his "please pull" emails and doing so only to
> find dozens of temporary tags fetched by the pull. Junio's patch (if I
> read it correctly) unconditionally fetches *ALL* tags reachable from
> the top of the commit-chain, which means there is no longer any way to
> keep temporary tags in a repo from which someone else will pull.

I thought we made fetch made by such a promiscous pull not to
follow tags, so that wouldn't be a problem.  Tag following is
only to happen when you track other's branches.  That is:

	$ git pull git://git.kernel.org/pub/scm/git/git.git master

would store my "master" branch tip only in your .git/FETCH_HEAD and
you merge it immediately, without following my tags, while:

	$ git pull git://git.kernel.org/pub/scm/git/git.git master:origin

(which is what you get by "git pull" without arguments) would
follow my tags, because you are storing the branch head into
your local branch "origin".

> I for one riddle my repos with temporary tags whenever I'm trying
> something I'm not so sure of, or find an interesting bug or a design
> decision I'm not 100% sure of. Perhaps I should rather do this with
> branches, but imo branches are for doing work, whereas tags just mark
> a spot in the development so I easily can find them with gitk or some
> such.

I also have many throwaway unannotated tags.  Whenever I have a
WIP that I want to split up or reorder, I tag the tip of that
topic branch with "git tag anchor-blah" tag, rewind the tip to
the commit before the one I want to redo, and then do this
repeatedly:

	$ git diff -R anchor-blah >P.diff
        $ ... edit P.diff to keep the part I want to apply first
        $ git apply --index P.diff
        $ ... maybe edit a bit further
        $ git commit

until there is no difference between the rewound-and-redone tip
and anchor-blah other than whatever clean-ups I do during the
above cycle.  Propagating such throw-away tags is not very
useful.  And I think it is reasonable to say that throw-away
tags tend to be unannotated.

Re: Pulling tags from git.git

[A Large Angry SCM]

Andreas Ericsson wrote:
> A Large Angry SCM wrote:
>> Andreas Ericsson wrote:
>>
>>> Junio C Hamano wrote:
>>>
>>>> Andreas Ericsson <ae@op5.se> writes:
>>>>
>>>>
>>>>> With the git or git+ssh protocol, tags will be autofollowed
>>>>> when you do a pull (only signed tags, I think).  The
>>>>> auto-following is done by detecting tags that are fetched,
>>>>
>>>>
>>>>
>>>> Ah, you are correct.  We do not follow lightweight tags; I am
>>>> not sure if we should.
>>>>
>>>
>>> I'm fairly sure we shouldn't. The default update-hook prevents them 
>>> (if enabled), and I can't for the life of me think of why anyone 
>>> would want to distribute such tags.
>>>
>>> OTOH, preventing unannotated tags from being pushed seems like a 
>>> better way than to not have the ability to auto-follow those same 
>>> tags. After all, it's better to discourage than to disallow.
>>>
>>
>> Before you do this, please explain why unannotated tags are not 
>> useful, and so should not be allowed to be pushed.
> 
> 
> Imagine Linus, getting his "please pull" emails and doing so only to 
> find dozens of temporary tags fetched by the pull. Junio's patch (if I 
> read it correctly) unconditionally fetches *ALL* tags reachable from the 
> top of the commit-chain, which means there is no longer any way to keep 
> temporary tags in a repo from which someone else will pull.

Why is a "pull" bothering with tags? A "fetch" yes, but not a pull.

> I for one riddle my repos with temporary tags whenever I'm trying 
> something I'm not so sure of, or find an interesting bug or a design 
> decision I'm not 100% sure of. Perhaps I should rather do this with 
> branches, but imo branches are for doing work, whereas tags just mark a 
> spot in the development so I easily can find them with gitk or some such.
> 
> I may be biased by the way we do things at work. In our workflow, all 
> tags meant to be distributed have a short note in them which explains 
> the rationale of the tag. For example, new versions have a very brief 
> changelog that sales-people get on email (a blessing, that, since we 
> devs no longer have to update feature-lists and such).
> 
> Tags not meant to be distributed are unannotated, and unannotated tags 
> are kept out of published repos which are always stored at a central 
> server. Everybody synchronize to those central repos, so nobody pulls 
> from each other. Perhaps this is how the kernel devs work too, but if it 
> ever changes the update hook will no longer be able to safeguard from it 
> and the, in my eyes, temporary tags will be distributed in a 
> criss-crossing mesh so no-one will ever know where it came from or who 
> created it or why. I.e. a Bad Thing.

The distinction here is not annotated tags or temporary tags but _local_ 
tags. _Your_ workflow conventions treat unannotated tags as local tags 
but declaring that unannotated tags can not be pushed is imposing _your_ 
conventions on other groups. Just as branch names, themselves, can be 
meaningful, so can tag names.

Re: Pulling tags from git.git

[Andreas Ericsson]

A Large Angry SCM wrote:
> 
> Why is a "pull" bothering with tags? A "fetch" yes, but not a pull.
> 

A pull is a fetch + merge. I said pull because what little I know of 
Linus' workflow is the the emails he gets from susbsystem maintainers 
are called "pull requests".

>>
>> Tags not meant to be distributed are unannotated, and unannotated tags 
>> are kept out of published repos which are always stored at a central 
>> server. Everybody synchronize to those central repos, so nobody pulls 
>> from each other. Perhaps this is how the kernel devs work too, but if 
>> it ever changes the update hook will no longer be able to safeguard 
>> from it and the, in my eyes, temporary tags will be distributed in a 
>> criss-crossing mesh so no-one will ever know where it came from or who 
>> created it or why. I.e. a Bad Thing.
> 
> 
> The distinction here is not annotated tags or temporary tags but _local_ 
> tags. _Your_ workflow conventions treat unannotated tags as local tags 
> but declaring that unannotated tags can not be pushed is imposing _your_ 
> conventions on other groups. Just as branch names, themselves, can be 
> meaningful, so can tag names.
> 

Yes, that's why I said it's better to discourage than to disallow. The 
default update-hook is disabled by default and there are comments 
aplenty to make it possible even for the most die-hard point-and-click 
monkey to be able to comment out the disallowing of unannotated tags.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Pulling tags from git.git

[Florian Weimer]

* Andreas Ericsson:

[lightweight tags]

> I'm fairly sure we shouldn't. The default update-hook prevents them
> (if enabled), and I can't for the life of me think of why anyone would
> want to distribute such tags.

The current implementation is rather counter-intuitive because it's
much easier to create lightweight tags, and you wonder why they aren't
replicated by fetches (but some other tags are).

Re: Pulling tags from git.git

[Andreas Ericsson]

Florian Weimer wrote:
> * Andreas Ericsson:
> 
> [lightweight tags]
> 
> 
>>I'm fairly sure we shouldn't. The default update-hook prevents them
>>(if enabled), and I can't for the life of me think of why anyone would
>>want to distribute such tags.
> 
> 
> The current implementation is rather counter-intuitive because it's
> much easier to create lightweight tags, and you wonder why they aren't
> replicated by fetches (but some other tags are).


Well, you wouldn't want to go through the trouble of writing a 
tag-message for a temporary tag, but signing and writing a short note 
for a tag that you intend those who share your workload to have is not 
that much of a bother imo.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Pulling tags from git.git

[Florian Weimer]

* Andreas Ericsson:

>> The current implementation is rather counter-intuitive because it's
>> much easier to create lightweight tags, and you wonder why they aren't
>> replicated by fetches (but some other tags are).

> Well, you wouldn't want to go through the trouble of writing a
> tag-message for a temporary tag, but signing and writing a short note
> for a tag that you intend those who share your workload to have is not
> that much of a bother imo.

It's not obvious from the git-tag documentation that signing makes a
difference down the road in terms of replication.  IOW, I don't
question the distinction per se, but it's counter-intuitive if you
aren't told about it.

Re: Pulling tags from git.git

[Junio C Hamano]

Florian Weimer <fw@deneb.enyo.de> writes:

> It's not obvious from the git-tag documentation that signing makes a
> difference down the road in terms of replication.  IOW, I don't
> question the distinction per se, but it's counter-intuitive if you
> aren't told about it.

Agreed.  Please make it so ;-).