{"thread":{"id":"27567","subject":"[rfd] auto-following tags upon \"git push\"?","startedAt":"2011-06-07T16:33:35Z","lastAt":"2011-06-07T23:23:01Z","messageCount":5,"participants":["Junio C Hamano","Shawn Pearce","Jeff King","Steffen Daode Nurpmeso"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"169452","messageId":"7v4o417g9s.fsf@alter.siamese.dyndns.org","threadId":"27567","inReplyTo":null,"subject":"[rfd] auto-following tags upon \"git push\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-07T16:33:35Z","receivedAt":"2011-06-07T16:33:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It has been a very conscious design decision that \"git push\" does not push\ntags without being told, as opposed to \"git fetch\" that can fetch tags\nthat point at commits that are being transferred.\n\nThe rationale is quite obvious, once you think about it. When fetching,\nyou are interacting with a remote repository somebody has published, which\nmeans two important things: (1) the set of tags that exist there are all\nthe publisher wanted people to see, and (2) not only you but other people\nwill also see the same tags. In other words, tags in repositories you\nfetch from are designed to be public and shared. It will facilitate\ncommunication between developers if it is easy for everybody to fetch\nthese same tags.\n\nWhen pushing, you are pushing from your working repository, which most of\nthe time is not public, and tags in that repository is not designed to be\npublic. You can use your own local tags to mark your progress, so it does\nnot make sense to blindly push all tags in your repository to the\nrepository you are pushing to publish your changes, whose tags are by\ndefinition public.\n\n\tSide note: the same logic applies to pushing branches. The\n\tbranches in the remote you fetch from are public, the ones in your\n\trepository are mixture of branches for your private work and\n\tbranches for public consumption.\n\nSo the recommended workflow for publishers has always been:\n\n - work on private topic branches that do not have corresponding branches\n   at the publishing repository to cook your work-in-progress;\n\n - integrate them when they are done to branches that do have\n   corresponding branches at the publishing repository;\n\n - \"git push\" without any extra configuration will push \"matching\"\n   branches, so that your private topic branches will stay private, and\n   the integration branches used to communicate with everybody else will\n   be pushed;\n\n - You can use a private tag to mark your point if you want to, and\n   you can tag a release on a branch that is shared with public.\n\n - A new branch, or a new tag to be made public needs to be pushed\n   explicitly. Requiring an explicit push, instead of blindly pushing\n   everything, avoids contaminating the ref namespace of the public\n   repository with your private topic branches and private tags by\n   accident.\n\nBut we could do better.\n\nTags are designed to promote sharing of common reference points; the goal\nis to ensure that within the scope of a project, when somebody says v1.0\nis buggy, everybody else knows exactly which version v1.0 refers to (this\nis the primary reason why we do not use separate-remote layout for tags).\n\nWhich also means that there is a social convention among everybody in the\nproject how public tags are named. Using a tag v2.4.3 to mark your private\nprogress point, when the project uses tags that match \"v*.*.*\" to mark\npublic releases, is not something any sane person would do.\n\nSo, while we still should _never_ automatically push any tag that points\nat a commit that is being pushed out (i.e. inverse of \"fetch\" that auto\nfollows tags), if the user or the project can give a clear enough hint to\ngit which tags are for public consumption, we should at least be able to\npush tags that are for public consumption and do point at commits that are\nbeing pushed out.\n\nThis is just me thinking out loud, but a typical end-user transcript may\nlook something like this:\n\n   Tell git that v*.* and v*.*.* are release tags (one-time set-up).\n   $ git config --unset-all push.autotag\n   $ git config --add push.autotag 'v*.*'\n   $ git config --add push.autotag 'v*.*.*'\n\n   Usual development process.\n   $ git checkout master\n   $ work work work\n\n   Not very happy as the result is a mess, but it seems to work Ok.\n   $ git tag wip\n\n   Try it again with the wisdom gained from the previous attempt.\n   $ rework rework rework\n\n   How much improvement did we make? Hmm, looks good.\n   $ git diff wip\n\n   Use that for the release.\n   $ git tag v1.2.0\n\n   Push it out, with the usual matching (or \"upstream\") semantics plus\n   the new auto-follow tags feature. Note that \"wip\" tag will not be sent.\n   $ git push\n"},{"id":"169467","messageId":"BANLkTikyd9x6+CBdq_yBTPCNYXWVq9qKF+MXbPMk2QRqmU0qhA@mail.gmail.com","threadId":"27567","inReplyTo":"7v4o417g9s.fsf@alter.siamese.dyndns.org","subject":"Re: [rfd] auto-following tags upon \"git push\"?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-06-07T17:21:29Z","receivedAt":"2011-06-07T17:21:29Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Jun 7, 2011 at 09:33, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Which also means that there is a social convention among everybody in the\n> project how public tags are named. Using a tag v2.4.3 to mark your private\n> progress point, when the project uses tags that match \"v*.*.*\" to mark\n> public releases, is not something any sane person would do.\n...\n> This is just me thinking out loud, but a typical end-user transcript may\n> look something like this:\n>\n>   Tell git that v*.* and v*.*.* are release tags (one-time set-up).\n>   $ git config --unset-all push.autotag\n>   $ git config --add push.autotag 'v*.*'\n>   $ git config --add push.autotag 'v*.*.*'\n...\n>   $ git tag v1.2.0\n>\n>   Push it out, with the usual matching (or \"upstream\") semantics plus\n>   the new auto-follow tags feature. Note that \"wip\" tag will not be sent.\n>   $ git push\n\nQuestions:\n\nDoes push.autotag apply to all remotes? I'm debating with myself if I\nreally want a tag I have created locally immediately pushed to a\nbackup repository. Just because I have tagged something on my primary\nwork repository, doesn't mean I want that public yet. I may have\ntemporarily tagged something, started building a release, then run a\n\"git push backup\" to send my branch tips to a private backup\nrepository and jumped on the transit system to head home.\nAutomatically pushing my newly created tag to my backup may be useful,\nbut if I later move that tag before I make it public pushes to my\nbackup might start failing. If my backup remote doesn't have a\nremote.backup.push refspec that includes refs/tags/* namespace, should\npush.autotag really send there?\n\nDoes push.autotag trigger if I specify push refspecs on the command\nline? It probably should, as the user might have specifically\nconfigured certain refs (maint, master, next, pu, todo) to be\npublished. Unless the user is pushing to Gerrit Code Review's magical\n\"refs/for/*\" destination namespace... in which case that tag might\nstill only be a tentative tag and isn't really part of the project\nhistory yet.\n\n\nIn general I agree with this idea. Its similar to the tag following we\nare doing on fetch/clone, and its similar to the tag visibility that\nGerrit Code Review does with per-branch access controls.\n\nUnfortunately you need to configure the patterns up front. This is\nadvanced user space. But the feature is most likely to help the new\nproject maintainer more than an existing user.\n\n-- \nShawn.\n"},{"id":"169471","messageId":"20110607173051.GA22216@sigill.intra.peff.net","threadId":"27567","inReplyTo":"7v4o417g9s.fsf@alter.siamese.dyndns.org","subject":"Re: [rfd] auto-following tags upon \"git push\"?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-06-07T17:30:51Z","receivedAt":"2011-06-07T17:30:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 07, 2011 at 09:33:35AM -0700, Junio C Hamano wrote:\n\n> So, while we still should _never_ automatically push any tag that points\n> at a commit that is being pushed out (i.e. inverse of \"fetch\" that auto\n> follows tags), if the user or the project can give a clear enough hint to\n> git which tags are for public consumption, we should at least be able to\n> push tags that are for public consumption and do point at commits that are\n> being pushed out.\n> \n> This is just me thinking out loud, but a typical end-user transcript may\n> look something like this:\n> \n>    Tell git that v*.* and v*.*.* are release tags (one-time set-up).\n>    $ git config --unset-all push.autotag\n>    $ git config --add push.autotag 'v*.*'\n>    $ git config --add push.autotag 'v*.*.*'\n\nHmm. Is it a clear enough hint when the user uses an actual tag object\nto make a signed or annotated tag? At least for me, private throw-away\ntags tend to just be refs/tags/foo pointing to a commit, and real,\nfor-public-consumption tags at least get an annotation, if not a\nsignature.\n\nI seem to recall we make a similar distinction somewhere else in the\ncode, but I can't remember offhand where. Maybe it was just a proposal\nthat never made it anywhere.\n\nAnyway, the problem would be somebody who does something like:\n\n  $ git tag -m \"here is a description of how this wip is going\" foo-wip\n\nwhich violates the assumption above. I have no idea how common that is\n(I tend to write such descriptions into a WIP commit message, and if I\nreally want to, tag the resulting commit directly).\n\n-Peff\n"},{"id":"169488","messageId":"7vpqmp5vl3.fsf@alter.siamese.dyndns.org","threadId":"27567","inReplyTo":"20110607173051.GA22216@sigill.intra.peff.net","subject":"Re: [rfd] auto-following tags upon \"git push\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-07T18:45:44Z","receivedAt":"2011-06-07T18:45:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Hmm. Is it a clear enough hint when the user uses an actual tag object\n> to make a signed or annotated tag? At least for me, private throw-away\n> tags tend to just be refs/tags/foo pointing to a commit, and real,\n> for-public-consumption tags at least get an annotation, if not a\n> signature.\n>\n> I seem to recall we make a similar distinction somewhere else in the\n> code, but I can't remember offhand where. Maybe it was just a proposal\n> that never made it anywhere.\n\nYou are thinking about \"describe\", I think, and the analogy holds\ntrue. The tag annotation vs lightweight tag is a good hint I forgot to\ntake into account.\n\n> Anyway, the problem would be somebody who does something like:\n>\n>   $ git tag -m \"here is a description of how this wip is going\" foo-wip\n>\n> which violates the assumption above.\n\nTrue, I think I did that sometimes.\n\nI personally do not use \"private tags\" that much anymore; I make liberal\nuse of private branches for that kind of work instead, as it is more\nflexible (I can check it out, build on it, rebase -i, and generally whip\nit around in any other way).\n"},{"id":"169527","messageId":"20110607232301.GB28023@sherwood.local","threadId":"27567","inReplyTo":"7v4o417g9s.fsf@alter.siamese.dyndns.org","subject":"Re: [rfd] auto-following tags upon \"git push\"?","fromName":"Steffen Daode Nurpmeso","fromEmail":"sdaoden@googlemail.com","sentAt":"2011-06-07T23:23:01Z","receivedAt":"2011-06-07T23:23:01Z","isPatch":false,"sender":{"key":"sdaoden@googlemail.com","avatar":null},"body":"If there would be a free bit somewhere in a tag object (or so):\n\n    $ git tag --autopush -ma \"This will be pushed along it's commit\" T1\n\nThis i would understand at a glance!\nAnd it is both, explicit on the one and automatic on the other\nhand.  I.e.: work, work, work - commit & tag, hours pass until\ninternet access and then\n\n    $ if-up-and-push-it-all-and-if-down.sh\n\n.. and that would only do 'cd repo && git push'.\nBut having a short look into tag.c does not give much hope on that.\nMaybe a new file .git/AUTOPUSH to which all SHA-1 to be\npushed automatically are simply appended.\n\n@ Junio C Hamano <gitster@pobox.com> wrote:\n>    Tell git that v*.* and v*.*.* are release tags (one-time set-up).\n>    $ git config --unset-all push.autotag\n>    $ git config --add push.autotag 'v*.*'\n>    $ git config --add push.autotag 'v*.*.*'\n\nI will blow that one, one of these days.\n\n@ Jeff King <peff@peff.net> wrote:\n> Hmm. Is it a clear enough hint when the user uses an actual tag\n> object to make a signed or annotated tag? At least for me,\n> private throw-away tags tend to just be refs/tags/foo pointing\n> to a commit, and real, for-public-consumption tags at least get\n> an annotation, if not a signature.\n> [.] Anyway, the problem would be somebody who does something like:\n>\n>  $ git tag -m \"here is a description of how this wip is going\" foo-wip\n>\n> which violates the assumption above. I have no idea how common that is\n\nI did understand that -m/-F required storage and thus force\ncreation of a tag object.  But hey - it's a bit odd, isn't it?\n(Thinking about it some more it's very convenient that the\npossibility exists.  But it will require more than one glance.\nYou know - that's ok for me, given all those features which will\nmake life easier once they're discovered and understood.)\n--\nCiao, Steffen\nsdaoden(*)(gmail.com)\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n"}]}