{"thread":{"id":"27557","subject":"Jabber, question on push,pull and --tags, and no help but jabber","startedAt":"2011-06-06T13:02:05Z","lastAt":"2011-06-11T17:20:48Z","messageCount":14,"participants":["Steffen Daode Nurpmeso","Michael J Gruber","Felipe Contreras","Victor Engmark","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"169362","messageId":"20110606130205.GA41674@sherwood.local","threadId":"27557","inReplyTo":null,"subject":"Jabber, question on push,pull and --tags, and no help but jabber","fromName":"Steffen Daode Nurpmeso","fromEmail":"sdaoden@googlemail.com","sentAt":"2011-06-06T13:02:05Z","receivedAt":"2011-06-06T13:02:05Z","isPatch":false,"sender":{"key":"sdaoden@googlemail.com","avatar":null},"body":"Hello GIT,\n first paragraph is reserved for praising your existence.\n 'Used cvs(1) for long years in small team projects with local\n private repos and never felt the need for anything else. 2011\n is different. I first tried you but failed resoundingly. Due\n to vim(1) and mutt(1) i discovered hg(1) and i still love it's\n simple usage. 'Talking about the front-end anyway. It's huge\n memory consumption and slow performance forbids it's usage on\n our old PCs (e.g. Cyrix 166+) though. So i came back and\n found you still receptive! And the more i work, the less\n i hurt, the greater the knowledge, the smoother the\n interaction. Are you the final word on RC in the end?\n\nI stumbled over one thing i don't understand, because it seems\nillogical: why do i need to use --tags to force pushing of tags?\nBecause there is even a config option for the latter, i suspect\nthis is because of intention. It would be nice to get some\ninformation on the background of that, like a link to yet existing\ndocumentation. Anyway i was a bit astonished to look at some\nheavily scripted page of my free private repo webhoster :-) and\ndon't see any tags, even though i've pushed multiple times and\nv0.0.0 was created directly after the first commit. I would *not*\nhave detected that otherwise ...\n(Yes i know it's somewhat implied by 'git help push'..--tags.\nBut i'm blonde.)\n\nSome more i'll pack into this so that it's gone with the wind:\n\n- Due to my weak GPRS or noisy HDSPA radio connection here in the\n pampa :) i hope for continuable network actions - failing after\n 98% is a costly pain. So it was a real joy to read somewhere\n that a GSOC project will address this issue!!\n- OpenSSL support for signing. I don't use PGP/GPG. But i use\n HTTPS, POPS, SSH etc., so i'll have an OpenSSL/OpenSSH\n environment here on my box ready to use.\n\nThanks for GIT!\n--\nCiao, Steffen\nsdaoden(*)(gmail.com)\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n"},{"id":"169369","messageId":"4DECE4D6.9000204@drmicha.warpmail.net","threadId":"27557","inReplyTo":"20110606130205.GA41674@sherwood.local","subject":"Re: Jabber, question on push,pull and --tags, and no help but jabber","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-06-06T14:31:50Z","receivedAt":"2011-06-06T14:31:50Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 15:02:\n> Hello GIT,\n> first paragraph is reserved for praising your existence.\n> 'Used cvs(1) for long years in small team projects with local\n> private repos and never felt the need for anything else. 2011\n> is different. I first tried you but failed resoundingly. Due\n> to vim(1) and mutt(1) i discovered hg(1) and i still love it's\n> simple usage. 'Talking about the front-end anyway. It's huge\n> memory consumption and slow performance forbids it's usage on\n> our old PCs (e.g. Cyrix 166+) though. So i came back and\n> found you still receptive! And the more i work, the less\n> i hurt, the greater the knowledge, the smoother the\n> interaction. Are you the final word on RC in the end?\n> \n> I stumbled over one thing i don't understand, because it seems\n> illogical: why do i need to use --tags to force pushing of tags?\n> Because there is even a config option for the latter, i suspect\n> this is because of intention. It would be nice to get some\n> information on the background of that, like a link to yet existing\n> documentation. Anyway i was a bit astonished to look at some\n\nTags may contain private information. Say you pull some changes from\nyour head of group, find a strange commit you want to look at later and\ntag it with \"what-is-this-crap\"...\n\nMore seriously, tags are not part of the \"remotes layout\", so when you\npush them and others pull them they overwrite their tags if there's a\nname clash.\n\n> heavily scripted page of my free private repo webhoster :-) and\n> don't see any tags, even though i've pushed multiple times and\n> v0.0.0 was created directly after the first commit. I would *not*\n> have detected that otherwise ...\n> (Yes i know it's somewhat implied by 'git help push'..--tags.\n> But i'm blonde.)\n> \n> Some more i'll pack into this so that it's gone with the wind:\n> \n> - Due to my weak GPRS or noisy HDSPA radio connection here in the\n> pampa :) i hope for continuable network actions - failing after\n> 98% is a costly pain. So it was a real joy to read somewhere\n> that a GSOC project will address this issue!!\n> - OpenSSL support for signing. I don't use PGP/GPG. But i use\n> HTTPS, POPS, SSH etc., so i'll have an OpenSSL/OpenSSH\n> environment here on my box ready to use.\n\n\"git tag\" and \"git verify-tag\" call out to \"gpg\". That could be easily\nadapted to call out to \"openssl smime\", or put your S/MIME signatures in\na note.\n\nCheers\nMichael\n"},{"id":"169370","messageId":"BANLkTikYhWxONOCaPx7P0RX6By6GmEum=g@mail.gmail.com","threadId":"27557","inReplyTo":"4DECE4D6.9000204@drmicha.warpmail.net","subject":"Re: Jabber, question on push,pull and --tags, and no help but jabber","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-06-06T15:21:25Z","receivedAt":"2011-06-06T15:21:25Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 6, 2011 at 5:31 PM, Michael J Gruber\n wrote:\n> Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 15:02:\n>> Hello GIT,\n>>     first paragraph is reserved for praising your existence.\n>>     'Used cvs(1) for long years in small team projects with local\n>>     private repos and never felt the need for anything else.  2011\n>>     is different.  I first tried you but failed resoundingly.  Due\n>>     to vim(1) and mutt(1) i discovered hg(1) and i still love it's\n>>     simple usage.  'Talking about the front-end anyway.  It's huge\n>>     memory consumption and slow performance forbids it's usage on\n>>     our old PCs (e.g. Cyrix 166+) though.  So i came back and\n>>     found you still receptive!  And the more i work, the less\n>>     i hurt, the greater the knowledge, the smoother the\n>>     interaction.  Are you the final word on RC in the end?\n>>\n>> I stumbled over one thing i don't understand, because it seems\n>> illogical: why do i need to use --tags to force pushing of tags?\n>> Because there is even a config option for the latter, i suspect\n>> this is because of intention.  It would be nice to get some\n>> information on the background of that, like a link to yet existing\n>> documentation.  Anyway i was a bit astonished to look at some\n>\n> Tags may contain private information. Say you pull some changes from\n> your head of group, find a strange commit you want to look at later and\n> tag it with \"what-is-this-crap\"...\n>\n> More seriously, tags are not part of the \"remotes layout\", so when you\n> push them and others pull them they overwrite their tags if there's a\n> name clash.\n\nUntil tag namespaces are merged.\n\n-- \nFelipe Contreras\n"},{"id":"169371","messageId":"20110606153405.GA15894@victor.terreactive.ch","threadId":"27557","inReplyTo":"9215090.63086.1307370716794.JavaMail.trustmail@mail1.terreactive.ch","subject":"Re: Jabber, question on push,pull and --tags, and no help but jabber","fromName":"Victor Engmark","fromEmail":"victor.engmark@terreactive.ch","sentAt":"2011-06-06T15:34:05Z","receivedAt":"2011-06-06T15:34:05Z","isPatch":false,"sender":{"key":"victor.engmark@terreactive.ch","avatar":null},"body":"On Mon, Jun 06, 2011 at 04:31:50PM +0200, Michael J Gruber wrote:\n> Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 15:02:\n> > Hello GIT,\n> > first paragraph is reserved for praising your existence.\n> > 'Used cvs(1) for long years in small team projects with local\n> > private repos and never felt the need for anything else. 2011\n> > is different. I first tried you but failed resoundingly. Due\n> > to vim(1) and mutt(1) i discovered hg(1) and i still love it's\n> > simple usage. 'Talking about the front-end anyway. It's huge\n> > memory consumption and slow performance forbids it's usage on\n> > our old PCs (e.g. Cyrix 166+) though. So i came back and\n> > found you still receptive! And the more i work, the less\n> > i hurt, the greater the knowledge, the smoother the\n> > interaction. Are you the final word on RC in the end?\n> > \n> > I stumbled over one thing i don't understand, because it seems\n> > illogical: why do i need to use --tags to force pushing of tags?\n> > Because there is even a config option for the latter, i suspect\n> > this is because of intention. It would be nice to get some\n> > information on the background of that, like a link to yet existing\n> > documentation. Anyway i was a bit astonished to look at some\n> \n> Tags may contain private information. Say you pull some changes from\n> your head of group, find a strange commit you want to look at later and\n> tag it with \"what-is-this-crap\"...\n\nYou could use the same argument about commit log messages, branch names\nand code comments. No go ;)\n\n> More seriously, tags are not part of the \"remotes layout\", so when you\n> push them and others pull them they overwrite their tags if there's a\n> name clash.\n\nThat's odd - I wouldn't expect anything handled by Git to be simply\noverwritten without merging. Is there some technical reason for this, or\nis it just not implemented yet?\n\nIf it makes more sense to casual users, how about simply making --tags\nthe default, and --no-tags optional?\n\nCheers\n-- \nVictor\nterreActive AG\nKasinostrasse 30\nCH-5001 Aarau\nTel: +41 62 834 00 55\nFax: +41 62 823 93 56\nwww.terreactive.ch\n\nWir sichern Ihren Erfolg - seit 15 Jahren\n"},{"id":"169384","messageId":"7v1uz6alkv.fsf@alter.siamese.dyndns.org","threadId":"27557","inReplyTo":"20110606153405.GA15894@victor.terreactive.ch","subject":"Re: Jabber, question on push,pull and --tags, and no help but jabber","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-06T17:58:24Z","receivedAt":"2011-06-06T17:58:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Victor Engmark writes:\n\n>> More seriously, tags are not part of the \"remotes layout\", so when you\n>> push them and others pull them they overwrite their tags if there's a\n>> name clash.\n>\n> That's odd - I wouldn't expect anything handled by Git to be simply\n> overwritten without merging. Is there some technical reason for this, or\n> is it just not implemented yet?\n\nBranches are something you work on by looking at other people's progress,\nso remote layout to copy his master branch to refs/remotes/his/master so\nthat you can compare it with yours with \"git diff his/master master\" or\nmerge his effort into yours with \"git merge his/master\" makes sense.\n\nTags are something that is to be _shared_ amongst people, and having v1.4.3\nthat is different depending on which member of the same project you ask is\na road to insanity, hence we don't do refs/remotes/his/v1.4.3 that could\nbe different from the project's global refs/tags/v1.4.3 to reduce the risk\nof confusion.\n"},{"id":"169413","messageId":"20110606214639.GA38620@sherwood.local","threadId":"27557","inReplyTo":"4DECE4D6.9000204@drmicha.warpmail.net","subject":"Re: Jabber, question on push,pull and --tags, and no help but jabber","fromName":"Steffen Daode Nurpmeso","fromEmail":"sdaoden@googlemail.com","sentAt":"2011-06-06T21:46:39Z","receivedAt":"2011-06-06T21:46:39Z","isPatch":false,"sender":{"key":"sdaoden@googlemail.com","avatar":null},"body":"@ Michael J Gruber wrote (2011-06-06 16:31+0200):\n> \"git tag\" and \"git verify-tag\" call out to \"gpg\". That could be easily\n> adapted to call out to \"openssl smime\", or put your S/MIME signatures in\n> a note.\n> \n> Cheers\n> Michael\n\nHum. It will indeed be possible to place a wrapper script 'gpg'\nin the path on my box (and catch '--verify' - or sign otherwise).\n\nBut in the meanwhile i've found out that git(1) is heavily\ndeveloped, stale .git_vtag_ files of an 1.7.3? version are no\nlonger produced by 'git version 1.7.6.rc0' to which i've updated\nafter i've seen those. So maybe there is hope that the hardcoded\ngpg invocation will be replaced by configuration options in the\nfuture, too?\n\nI still don't understand the design with pull and --tags.\nBecause, if i do 'git log' it'll display the relationship as in\n\n commit fd040fb[...] (tag: refs/tags/v0.3.0, refs/remotes/origin/master)\n\nSo i'll push this commit object as part of pushing a branch, and\nthe tag refers to *it*. I don't want to be impertinent though,\nand it's better that explicit way than implicitely pushing some\ndistressing stuff. Still i would have appreciated a note in the\ndocu, because it took a look at the mentioned webspace to realize\nthe situation. I'll append a short diff to be able to provide\nsomething useful. (No attachments allowed here i guess.)\n\nI'll try to be less tiny from the start the next time.\n--\nCiao, Steffen\nsdaoden(*)(gmail.com)\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n\n--\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 88acfcd..da4a71a 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -69,7 +69,7 @@ nor in any Push line of the corresponding remotes file---see below).\n \n --all::\n \tInstead of naming each ref to push, specifies that all\n-\trefs under `refs/heads/` be pushed.\n+\trefs under `refs/heads/` be pushed explicitely.\n \n --mirror::\n \tInstead of naming each ref to push, specifies that all\n@@ -98,7 +98,7 @@ nor in any Push line of the corresponding remotes file---see below).\n --tags::\n \tAll refs under `refs/tags` are pushed, in\n \taddition to refspecs explicitly listed on the command\n-\tline.\n+\tline. Note that tags are not pushed automatically.\n \n --receive-pack=::\n --exec=::\n"},{"id":"169427","messageId":"4DEDBB56.7000200@drmicha.warpmail.net","threadId":"27557","inReplyTo":"20110606214639.GA38620@sherwood.local","subject":"Re: Jabber, question on push,pull and --tags, and no help but jabber","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-06-07T05:47:02Z","receivedAt":"2011-06-07T05:47:02Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 23:46:\n> @ Michael J Gruber wrote (2011-06-06 16:31+0200):\n>> \"git tag\" and \"git verify-tag\" call out to \"gpg\". That could be easily\n>> adapted to call out to \"openssl smime\", or put your S/MIME signatures in\n>> a note.\n>>\n>> Cheers\n>> Michael\n> \n> Hum. It will indeed be possible to place a wrapper script 'gpg'\n> in the path on my box (and catch '--verify' - or sign otherwise).\n\nI didn't mean to shove a disguised openssl-smime into the path, I meant\nthat that there is little to change in code because git calls out to gpg\nrather than doing it itself.\n\n> But in the meanwhile i've found out that git(1) is heavily\n> developed, stale .git_vtag_ files of an 1.7.3? version are no\n> longer produced by 'git version 1.7.6.rc0' to which i've updated\n> after i've seen those. So maybe there is hope that the hardcoded\n> gpg invocation will be replaced by configuration options in the\n> future, too?\n\nI don't know if it needs to be configurable. That may open a can of worms.\n\n> I still don't understand the design with pull and --tags.\n> Because, if i do 'git log' it'll display the relationship as in\n> \n> commit fd040fb[...] (tag: refs/tags/v0.3.0, refs/remotes/origin/master)\n\ngit log does that only when you ask it to decorate the commits.\n\"decoration\" means looking up all refs and checking whether one of them\nreferences that commit. Neither the tag (object) nor the ref names (tag\nname, branch name) are part of the commit, so:\n\n> So i'll push this commit object as part of pushing a branch, and\n> the tag refers to *it*. I don't want to be impertinent though,\n\nThe tag name is not pushed, but the commit object is and has the same\nsha1 on \"both sides\", which is why the remote branch name shows up as a\ndecoration.\n\n> and it's better that explicit way than implicitely pushing some\n> distressing stuff. Still i would have appreciated a note in the\n> docu, because it took a look at the mentioned webspace to realize\n> the situation. I'll append a short diff to be able to provide\n> something useful. (No attachments allowed here i guess.)\n> \n> I'll try to be less tiny from the start the next time.\n> --\n> Ciao, Steffen\n> sdaoden(*)(gmail.com)\n> () ascii ribbon campaign - against html e-mail\n> /\\ www.asciiribbon.org - against proprietary attachments\n> \n> --\n> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\n> index 88acfcd..da4a71a 100644\n> --- a/Documentation/git-push.txt\n> +++ b/Documentation/git-push.txt\n> @@ -69,7 +69,7 @@ nor in any Push line of the corresponding remotes file---see below).\n> \n> --all::\n> \tInstead of naming each ref to push, specifies that all\n> -\trefs under `refs/heads/` be pushed.\n> +\trefs under `refs/heads/` be pushed explicitely.\n\nI don't mind but I don't think it adds clarity.\n\n> \n> --mirror::\n> \tInstead of naming each ref to push, specifies that all\n> @@ -98,7 +98,7 @@ nor in any Push line of the corresponding remotes file---see below).\n> --tags::\n> \tAll refs under `refs/tags` are pushed, in\n> \taddition to refspecs explicitly listed on the command\n> -\tline.\n> +\tline. Note that tags are not pushed automatically.\n\nThat is implicit in the line before it. In any case: The main problem of\ngit-push(1) seems to be that one has to read all the way down (through\nall options) in order to grasp the default case, so I feel the first\nparagraph needs to improve.\n\n> \n> --receive-pack=::\n> --exec=::\n> \n"},{"id":"169433","messageId":"20110607102444.GA85904@sherwood.local","threadId":"27557","inReplyTo":"4DEDBB56.7000200@drmicha.warpmail.net","subject":"Re: Jabber, question on push,pull and --tags, and no help but jabber","fromName":"Steffen Daode Nurpmeso","fromEmail":"sdaoden@googlemail.com","sentAt":"2011-06-07T10:24:44Z","receivedAt":"2011-06-07T10:24:44Z","isPatch":false,"sender":{"key":"sdaoden@googlemail.com","avatar":null},"body":"@ Michael J Gruber wrote (2011-06-07 07:47+0200):\n> > +\trefs under `refs/heads/` be pushed explicitely.\n> \n> I don't mind but I don't think it adds clarity.\n\nYes you're right - it was around midnight and i was tired.\nThat's a stupid change.\n\n> That is implicit in the line before it. In any case: The main problem of\n> git-push(1) seems to be that one has to read all the way down (through\n> all options) in order to grasp the default case, \n\nIn fact i'm lazy, so i'll assume that hardly happens until the\nfirst error occurs :).\n\n> so I feel the first paragraph needs to improve.\n\nThis morning i've reread tutorial(-2)? and user-manual, which,\nplus core-tutorial, where the files i've really read :-).\nAnd guess what, in neither of these files you will find a single\nword or even example about this, but the talk is only on branches!\neveryday.txt and gitworkflows.txt, however, give you\n\n <13> push the tag out, too.\n..\n You need to push the new tag to a public git serve..\n This makes the tag available\n\nInteresting \", too\" and \"You need to\" that is, maybe ;-/.\nI'll propose for real fewest minor changes in the documentation,\nso that users get a glance on that fact. I would assume that\nthese few lines would have been enough for me to \"get a starter\".\n\nThanks for the responses.\n(By the way: \"an arbitrary SHA-1 expression will do\" sounds like\nit's talking about a cool and flexible software.)\n--\nCiao, Steffen\nsdaoden(*)(gmail.com)\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n"},{"id":"169434","messageId":"1307443713-14534-1-git-send-email-sdaoden@gmail.com","threadId":"27557","inReplyTo":"20110606130205.GA41674@sherwood.local","subject":"[PATCH] Notes that tags need to pushed explicitely","fromName":"Steffen Daode Nurpmeso","fromEmail":"sdaoden@googlemail.com","sentAt":"2011-06-07T10:48:33Z","receivedAt":"2011-06-07T10:48:33Z","isPatch":true,"sender":{"key":"sdaoden@googlemail.com","avatar":null},"body":"---\n Documentation/git-tag.txt | 3 ++-\n Documentation/gittutorial.txt | 1 +\n 2 files changed, 3 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt\nindex d82f621..242837f 100644\n--- a/Documentation/git-tag.txt\n+++ b/Documentation/git-tag.txt\n@@ -27,7 +27,8 @@ Unless `-f` is given, the tag to be created must not yet exist in the\n If one of `-a`, `-s`, or `-u ` is passed, the command\n creates a 'tag' object, and requires a tag message. Unless\n `-m ` or `-F ` is given, an editor is started for the user to type\n-in the tag message.\n+in the tag message. Tag objects can be pushed upstream with\n+linkgit:git-push[1].\n \n If `-m ` or `-F ` is given and `-a`, `-s`, and `-u `\n are absent, `-a` is implied.\ndiff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt\nindex 0982f74..08c0c3a 100644\n--- a/Documentation/gittutorial.txt\n+++ b/Documentation/gittutorial.txt\n@@ -520,6 +520,7 @@ names. For example:\n \n -------------------------------------\n $ git diff v2.5 HEAD\t # compare the current HEAD to v2.5\n+$ git push v2.5\t\t # push the tag upstream\n $ git branch stable v2.5 # start a new branch named \"stable\" based\n \t\t\t # at v2.5\n $ git reset --hard HEAD^ # reset your current branch and working\n-- \n1.7.6.rc0\n"},{"id":"169447","messageId":"7vk4cx7mst.fsf@alter.siamese.dyndns.org","threadId":"27557","inReplyTo":"1307443713-14534-1-git-send-email-sdaoden@gmail.com","subject":"Re: [PATCH] Notes that tags need to pushed explicitely","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-07T14:12:34Z","receivedAt":"2011-06-07T14:12:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Daode Nurpmeso writes:\n\n> ---\n\nSign-off?\n\n> Documentation/git-tag.txt | 3 ++-\n> Documentation/gittutorial.txt | 1 +\n> 2 files changed, 3 insertions(+), 1 deletions(-)\n>\n> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt\n> index d82f621..242837f 100644\n> --- a/Documentation/git-tag.txt\n> +++ b/Documentation/git-tag.txt\n> @@ -27,7 +27,8 @@ Unless `-f` is given, the tag to be created must not yet exist in the\n> If one of `-a`, `-s`, or `-u ` is passed, the command\n> creates a 'tag' object, and requires a tag message. Unless\n> `-m ` or `-F ` is given, an editor is started for the user to type\n> -in the tag message.\n> +in the tag message. Tag objects can be pushed upstream with\n> +linkgit:git-push[1].\n> \n> If `-m ` or `-F ` is given and `-a`, `-s`, and `-u `\n> are absent, `-a` is implied.\n\nThis part of the patch looks sane and uncontroversial.\n\n> diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt\n> index 0982f74..08c0c3a 100644\n> --- a/Documentation/gittutorial.txt\n> +++ b/Documentation/gittutorial.txt\n> @@ -520,6 +520,7 @@ names. For example:\n> \n> -------------------------------------\n> $ git diff v2.5 HEAD\t # compare the current HEAD to v2.5\n> +$ git push v2.5\t\t # push the tag upstream\n> $ git branch stable v2.5 # start a new branch named \"stable\" based\n> \t\t\t # at v2.5\n> $ git reset --hard HEAD^ # reset your current branch and working\n\nThis feels way out of place in the context of the story the tutorial is\ntelling. These are examples that various ways to spell object names are\nused to identify a commit to commands that want to be given commits, but\n\"git push \" is _not_ an example of such a command. Also there is\nnothing in the vicinity that pushes a branch that contains the tagged\ncommit out; if the earlier example to create this v2.5 tag were done to\nmark a commit in an existing history you obtained from elsewhere, pushing\nthe tag alone might make sense, but usually you push branches out and then\noptionally tags that refer to commits on those branches.\n\nHow about adding an example in git-push section instead?\n\n Documentation/git-push.txt | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 88acfcd..363d3df 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -371,6 +371,11 @@ git push origin HEAD:master::\n \t`origin` repository. This form is convenient to push the current\n \tbranch without thinking about its local name.\n \n+git push origin tag v1.5::\n+\tPush the `v1.5` tag to the `origin` repository. A newly created\n+\ttag needs to be published explicitly like this, just like a newly\n+\tcreated branch does not get published automatically.\n+\n git push origin master:refs/heads/experimental::\n \tCreate the branch `experimental` in the `origin` repository\n \tby copying the current `master` branch. This form is only\n"},{"id":"169450","messageId":"20110607153323.GA71116@sherwood.local","threadId":"27557","inReplyTo":"7vk4cx7mst.fsf@alter.siamese.dyndns.org","subject":"[PATCH] Remarks that tags need to be pushed explicitly","fromName":"Steffen Daode Nurpmeso","fromEmail":"sdaoden@googlemail.com","sentAt":"2011-06-07T15:33:23Z","receivedAt":"2011-06-07T15:33:23Z","isPatch":true,"sender":{"key":"sdaoden@googlemail.com","avatar":null},"body":"@ Junio C Hamano wrote (2011-06-07 16:12+0200):\n> > diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt\n> This feels way out of place in the context of the story the tutorial is\n> telling.\n\nNo door gap at all for this in *tut* and user-manual!\n\n> How about adding an example in git-push section instead?\n\nI'll pack this in verbatim. :).\nYou'll notice that the patch also adds the word \"Utilize\" in front\nof `tag ` in the OPTIONS section. I did not even now that\nthe term \"tag\" can be used, but i'm afraid that i thought of that\nas a spelling error - on my terminal all these `terms` are not\nhighlighted in any special way. 'Would thus be good?\n__\nCiao, Steffen\nsdaoden(*)(gmail.com)\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n\n\nSigned-off-by: Steffen Daode Nurpmeso \n---\n Documentation/git-push.txt | 7 ++++++-\n Documentation/git-tag.txt | 3 ++-\n 2 files changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 88acfcd..898348a 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -55,7 +55,7 @@ you can tell git to update the ref even when the update is not a\n fast-forward. This does *not* attempt to merge into . See\n EXAMPLES below for details.\n +\n-`tag ` means the same as `refs/tags/:refs/tags/`.\n+Utilize `tag ` means the same as `refs/tags/:refs/tags/`.\n +\n Pushing an empty allows you to delete the ref from\n the remote repository.\n@@ -371,6 +371,11 @@ git push origin HEAD:master::\n \t`origin` repository. This form is convenient to push the current\n \tbranch without thinking about its local name.\n \n+git push origin tag v1.5::\n+ Push the `v1.5` tag to the `origin` repository. A newly created\n+ tag needs to be published explicitly like this, just like a newly\n+ created branch does not get published automatically.\n+\n git push origin master:refs/heads/experimental::\n \tCreate the branch `experimental` in the `origin` repository\n \tby copying the current `master` branch. This form is only\ndiff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt\nindex d82f621..242837f 100644\n--- a/Documentation/git-tag.txt\n+++ b/Documentation/git-tag.txt\n@@ -27,7 +27,8 @@ Unless `-f` is given, the tag to be created must not yet exist in the\n If one of `-a`, `-s`, or `-u ` is passed, the command\n creates a 'tag' object, and requires a tag message. Unless\n `-m ` or `-F ` is given, an editor is started for the user to type\n-in the tag message.\n+in the tag message. Tag objects can be pushed upstream with\n+linkgit:git-push[1].\n \n If `-m ` or `-F ` is given and `-a`, `-s`, and `-u `\n are absent, `-a` is implied.\n-- \n1.7.6.rc0\n"},{"id":"169862","messageId":"20110610203943.GA50937@sherwood.local","threadId":"27557","inReplyTo":"7vk4cx7mst.fsf@alter.siamese.dyndns.org","subject":"[PATCH v2] Remarks that tags need to be pushed explicitly","fromName":"Steffen Daode Nurpmeso","fromEmail":"sdaoden@googlemail.com","sentAt":"2011-06-10T20:39:43Z","receivedAt":"2011-06-10T20:39:43Z","isPatch":true,"sender":{"key":"sdaoden@googlemail.com","avatar":null},"body":"Well here is a somewhat more sophisticated version of this tiny\ndocumentation patch. I believe this is a good thing now for\nnewbie users who have not yet created any git(1) specific synapses\n(except for the term \"branch-related \", but \"any valid\n\" is a bit misleading since you will see nowhere that\n\"ref/tags/*\" is not a valid unless you know this is\na logical thing; heroes may know at a glance).\n\nI don't like gitworkflows.txt as a direct link after tutorial and\ntutorial-2. It's much too specialized in my eyes. What is really\nmissing here is a tutorial-3 which only talks about, and gives\nmyriads of examples for pull/fetch and push, including easy\nconfiguration examples and corner cases (like \"ref/tags/*\").\nMaybe in six month or a bit later i have gathered enough knowledge\nto be able to write that in theory. :)\n\nP.S.: And please forget that 'tag --autopush' idea. Not even\n'tag --autopush-to=REMOTE' seems to be sensible to me anymore\n(because it's much easier to script that locally than to support\nthat in git(1)).\n\nHave a nice weekend (if you can).\n--\nCiao, Steffen\nsdaoden(*)(gmail.com)\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n\n-- >8 --\nAn updated patch of the try to smoothly integrate some more\neasy informations about pushing of tags.\n\nSigned-off-by: Steffen Daode Nurpmeso \n---\n Documentation/git-push.txt | 10 +++++++---\n Documentation/git-tag.txt | 4 +++-\n Documentation/user-manual.txt | 6 +++---\n 3 files changed, 13 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 88acfcd..e3af6da 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -55,7 +55,7 @@ you can tell git to update the ref even when the update is not a\n fast-forward. This does *not* attempt to merge into . See\n EXAMPLES below for details.\n +\n-`tag ` means the same as `refs/tags/:refs/tags/`.\n+Use of `tag ` is identical to `refs/tags/:refs/tags/`.\n +\n Pushing an empty allows you to delete the ref from\n the remote repository.\n@@ -340,8 +340,8 @@ The default behavior of this command when no is given can be\n configured by setting the `push` option of the remote.\n +\n For example, to default to pushing only the current branch to `origin`\n-use `git config remote.origin.push HEAD`. Any valid (like\n-the ones in the examples below) can be configured as the default for\n+use `git config remote.origin.push HEAD`. Any valid branch-related \n+(like the ones in the examples below) can be configured as the default for\n `git push origin`.\n \n git push origin :::\n@@ -371,6 +371,10 @@ git push origin HEAD:master::\n \t`origin` repository. This form is convenient to push the current\n \tbranch without thinking about its local name.\n \n+git push origin tag v1.5::\n+\tPush the `v1.5` tag to the `origin` repository.\n+\tShort hand for `git push origin refs/tags/v1.5:refs/tags/v1.5`.\n+\n git push origin master:refs/heads/experimental::\n \tCreate the branch `experimental` in the `origin` repository\n \tby copying the current `master` branch. This form is only\ndiff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt\nindex d82f621..a4cd4c3 100644\n--- a/Documentation/git-tag.txt\n+++ b/Documentation/git-tag.txt\n@@ -27,7 +27,8 @@ Unless `-f` is given, the tag to be created must not yet exist in the\n If one of `-a`, `-s`, or `-u ` is passed, the command\n creates a 'tag' object, and requires a tag message. Unless\n `-m ` or `-F ` is given, an editor is started for the user to type\n-in the tag message.\n+in the tag message. Tag objects are shareable and can be pushed upstream with\n+linkgit:git-push[1].\n \n If `-m ` or `-F ` is given and `-a`, `-s`, and `-u `\n are absent, `-a` is implied.\n@@ -260,6 +261,7 @@ include::date-formats.txt[]\n \n SEE ALSO\n --------\n+linkgit:git-push[1].\n linkgit:git-check-ref-format[1].\n \n GIT\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex f13a846..168e530 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -643,9 +643,9 @@ $ git tag stable-1 1b2e1d63ff\n You can use stable-1 to refer to the commit 1b2e1d63ff.\n \n This creates a \"lightweight\" tag. If you would also like to include a\n-comment with the tag, and possibly sign it cryptographically, then you\n-should create a tag object instead; see the linkgit:git-tag[1] man page\n-for details.\n+comment with the tag, possibly sign the tag cryptographically, or publish the\n+tag in a shared repository, then you should create a tag object instead; see\n+the linkgit:git-tag[1] man page for details.\n \n [[browsing-revisions]]\n Browsing revisions\n-- \n1.7.6.rc0\n"},{"id":"169863","messageId":"7vboy5wfao.fsf@alter.siamese.dyndns.org","threadId":"27557","inReplyTo":"20110610203943.GA50937@sherwood.local","subject":"Re: [PATCH v2] Remarks that tags need to be pushed explicitly","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-10T21:24:31Z","receivedAt":"2011-06-10T21:24:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Daode Nurpmeso writes:\n\n> (except for the term \"branch-related \", but \"any valid\n> \" is a bit misleading since you will see nowhere that\n> \"ref/tags/*\" is not a valid unless you know this is\n> a logical thing; heroes may know at a glance).\n\nSorry, I do not understand this paragraph, nor why the hunk in your patch\nthat corresponds to this comment, is a good change.\n\nThe current document says that any valid can be configured as\nthe default to push for 'git push backup', so you could say\n\n [remote \"backup\"]\n\turl = /mnt/backup/my-project.git/\n \tpush = +refs/heads/*:refs/heads/*\n push = +refs/tags/*:refs/tags/*\n\nin your configuration file, and \"git push backup\" would save the branches\nand tags to your backup location.\n\nWhy should this paragraph discourage users to configure refspec that talk\nabout refs outside branch-related things?\n\n> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\n> index 88acfcd..e3af6da 100644\n> --- a/Documentation/git-push.txt\n> +++ b/Documentation/git-push.txt\n> ...\n> @@ -340,8 +340,8 @@ The default behavior of this command when no is given can be\n> configured by setting the `push` option of the remote.\n> +\n> For example, to default to pushing only the current branch to `origin`\n> -use `git config remote.origin.push HEAD`. Any valid (like\n> -the ones in the examples below) can be configured as the default for\n> +use `git config remote.origin.push HEAD`. Any valid branch-related \n> +(like the ones in the examples below) can be configured as the default for\n> `git push origin`.\n\n\n> @@ -371,6 +371,10 @@ git push origin HEAD:master::\n> \t`origin` repository. This form is convenient to push the current\n> \tbranch without thinking about its local name.\n> \n> +git push origin tag v1.5::\n> +\tPush the `v1.5` tag to the `origin` repository.\n> +\tShort hand for `git push origin refs/tags/v1.5:refs/tags/v1.5`.\n\nExisting documentation seems to say either \"shorthand\" (22 occurrences) or\n\"short-hand\" (12 occurrences).\n\n> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> index f13a846..168e530 100644\n> --- a/Documentation/user-manual.txt\n> +++ b/Documentation/user-manual.txt\n> @@ -643,9 +643,9 @@ $ git tag stable-1 1b2e1d63ff\n> You can use stable-1 to refer to the commit 1b2e1d63ff.\n> \n> This creates a \"lightweight\" tag. If you would also like to include a\n> -comment with the tag, and possibly sign it cryptographically, then you\n> -should create a tag object instead; see the linkgit:git-tag[1] man page\n> -for details.\n> +comment with the tag, possibly sign the tag cryptographically, or publish the\n> +tag in a shared repository, then you should create a tag object instead; see\n> +the linkgit:git-tag[1] man page for details.\n\nAddition of \"possibly sign\" is a good change, but it is perfectly OK to\npublish a lightweight tag by pushing it into a remote repository via \"git\npush\", so \"if you want to publish, you should create a tag object instead\"\nis a misguided suggestion.\n\nOther than that, the patch looks Ok to me.\n\nThanks.\n"},{"id":"169876","messageId":"20110611172048.GA57615@sherwood.local","threadId":"27557","inReplyTo":"7vboy5wfao.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] Remarks that tags need to be pushed explicitly","fromName":"Steffen Daode Nurpmeso","fromEmail":"sdaoden@googlemail.com","sentAt":"2011-06-11T17:20:48Z","receivedAt":"2011-06-11T17:20:48Z","isPatch":true,"sender":{"key":"sdaoden@googlemail.com","avatar":null},"body":"@ Junio C Hamano wrote (2011-06-10 23:24+0200):\n> Thanks.\n\nI'm simply completely missing the point sofar.\nSorry for the noise, all of you.\n--\nCiao, Steffen\nsdaoden(*)(gmail.com)\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n"}]}