# Pulling tags from git.git 15 messages from 2006-03-06 to 2006-03-20. Participants: David Ho, Andreas Ericsson, Junio C Hamano, A Large Angry SCM, Florian Weimer. Thread: https://gitlist.dev/t/3588 ## David Ho, 2006-03-06 18:44 Subject: Pulling tags from git.git Message-ID: <4dd15d180603061044h3f70d48bk8006c15e605fdca1@mail.gmail.com> URL: https://gitlist.dev/e/4dd15d180603061044h3f70d48bk8006c15e605fdca1%40mail.gmail.com ``` 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 ``` ## David Ho, 2006-03-06 18:54 Subject: Re: Pulling tags from git.git Message-ID: <4dd15d180603061054k36d1a434se7377ded1b3240bb@mail.gmail.com> URL: https://gitlist.dev/e/4dd15d180603061054k36d1a434se7377ded1b3240bb%40mail.gmail.com In-Reply-To: <4dd15d180603061044h3f70d48bk8006c15e605fdca1@mail.gmail.com> ``` 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 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 > ``` ## Andreas Ericsson, 2006-03-07 09:29 Subject: Re: Pulling tags from git.git Message-ID: <440D5285.3050401@op5.se> URL: https://gitlist.dev/e/440D5285.3050401%40op5.se In-Reply-To: <4dd15d180603061054k36d1a434se7377ded1b3240bb@mail.gmail.com> ``` 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 ``` ## Junio C Hamano, 2006-03-07 10:33 Subject: Re: Pulling tags from git.git Message-ID: <7voe0ilf25.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7voe0ilf25.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <440D5285.3050401@op5.se> ``` Andreas Ericsson 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 '') ;; ``` ## Andreas Ericsson, 2006-03-07 12:20 Subject: Re: Pulling tags from git.git Message-ID: <440D7A7D.8070507@op5.se> URL: https://gitlist.dev/e/440D7A7D.8070507%40op5.se In-Reply-To: <7voe0ilf25.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Andreas Ericsson 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 ``` ## A Large Angry SCM, 2006-03-07 14:37 Subject: Re: Pulling tags from git.git Message-ID: <440D9AB0.4070305@gmail.com> URL: https://gitlist.dev/e/440D9AB0.4070305%40gmail.com In-Reply-To: <440D7A7D.8070507@op5.se> ``` Andreas Ericsson wrote: > Junio C Hamano wrote: >> Andreas Ericsson 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. ``` ## Andreas Ericsson, 2006-03-07 15:35 Subject: Re: Pulling tags from git.git Message-ID: <440DA82D.3060909@op5.se> URL: https://gitlist.dev/e/440DA82D.3060909%40op5.se In-Reply-To: <440D9AB0.4070305@gmail.com> ``` A Large Angry SCM wrote: > Andreas Ericsson wrote: > >> Junio C Hamano wrote: >> >>> Andreas Ericsson 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 ``` ## David Ho, 2006-03-07 16:12 Subject: Re: Pulling tags from git.git Message-ID: <4dd15d180603070812u16fbcf58m4afea92293dce370@mail.gmail.com> URL: https://gitlist.dev/e/4dd15d180603070812u16fbcf58m4afea92293dce370%40mail.gmail.com In-Reply-To: <440D5285.3050401@op5.se> ``` 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 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. ``` ## Junio C Hamano, 2006-03-07 18:10 Subject: Re: Pulling tags from git.git Message-ID: <7vr75ejfd2.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr75ejfd2.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <440DA82D.3060909@op5.se> ``` Andreas Ericsson 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. ``` ## A Large Angry SCM, 2006-03-08 04:32 Subject: Re: Pulling tags from git.git Message-ID: <440E5E40.7090700@gmail.com> URL: https://gitlist.dev/e/440E5E40.7090700%40gmail.com In-Reply-To: <440DA82D.3060909@op5.se> ``` Andreas Ericsson wrote: > A Large Angry SCM wrote: >> Andreas Ericsson wrote: >> >>> Junio C Hamano wrote: >>> >>>> Andreas Ericsson 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. ``` ## Andreas Ericsson, 2006-03-08 10:13 Subject: Re: Pulling tags from git.git Message-ID: <440EAE34.5020807@op5.se> URL: https://gitlist.dev/e/440EAE34.5020807%40op5.se In-Reply-To: <440E5E40.7090700@gmail.com> ``` 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 ``` ## Florian Weimer, 2006-03-09 07:37 Subject: Re: Pulling tags from git.git Message-ID: <87zmk0dq75.fsf@mid.deneb.enyo.de> URL: https://gitlist.dev/e/87zmk0dq75.fsf%40mid.deneb.enyo.de In-Reply-To: <440D7A7D.8070507@op5.se> ``` * 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). ``` ## Andreas Ericsson, 2006-03-09 17:24 Subject: Re: Pulling tags from git.git Message-ID: <441064DD.2010903@op5.se> URL: https://gitlist.dev/e/441064DD.2010903%40op5.se In-Reply-To: <87zmk0dq75.fsf@mid.deneb.enyo.de> ``` 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 ``` ## Florian Weimer, 2006-03-20 18:30 Subject: Re: Pulling tags from git.git Message-ID: <87lkv5ynnp.fsf@mid.deneb.enyo.de> URL: https://gitlist.dev/e/87lkv5ynnp.fsf%40mid.deneb.enyo.de In-Reply-To: <441064DD.2010903@op5.se> ``` * 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. ``` ## Junio C Hamano, 2006-03-20 20:31 Subject: Re: Pulling tags from git.git Message-ID: <7vpskgkgcq.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vpskgkgcq.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <87lkv5ynnp.fsf@mid.deneb.enyo.de> ``` Florian Weimer 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 ;-). ```