{"thread":{"id":"34923","subject":"Local tag killer","startedAt":"2013-09-13T02:54:26Z","lastAt":"2013-10-01T12:45:57Z","messageCount":23,"participants":["Michael Haggerty","Junio C Hamano","John Szakmeister","Jeff King","Marc Branchaud","Nicolas Pitre","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"227604","messageId":"52327E62.2040301@alum.mit.edu","threadId":"34923","inReplyTo":null,"subject":"Local tag killer","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-09-13T02:54:26Z","receivedAt":"2013-09-13T02:54:26Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"A colleague of mine discovered, the hard way, that\n\n    git fetch --tags --prune $REMOTE\n\ndeletes all local tags that are not present on that particular remote.\nTo me this seems a dangerous and poorly-documented interaction of\nfeatures and arguably a bug.\n\nGranted, it might not be such a good idea to use local tags, as it is\nall to easy to push them inadvertently and then it is difficult to\nremove them permanently from a shared upstream repository because other\npeople might have fetched them and in turn inadvertently re-push them.\n\nBut the fact that combining two options, each of which seems safe and\nreasonable for daily use, results in the death of local tags unrelated\nto the remote is unexpected [1].  Also remember that the \"--prune\"\nfeature can be turned on permanently via \"git config\" using\n\"fetch.prune\" or \"remote.$REMOTE.prune\".\n\nMoreover, the documentation is misleading on this point:\n\n> -p::\n> --prune::\n> \tAfter fetching, remove any remote-tracking branches which\n> \tno longer exist\ton the remote.\n\nIt is a stretch for references under refs/tags/ to be called\n\"remote-tracking branches\", even if they exist as the target of the\nrefspec \"refs/tags/*:refs/tags/*\" that is implicitly added by the --tags\noption.\n\nI suggest that --prune should not touch references under refs/tags/\nregardless of whether they appear on the right side of explicit or\nimplicit refspecs.  If pruning tags is deemed to be essential, then\nthere should be a specific option (\"--prune-tags\"?) to request it.\n\n\nWhen looking into this, I found a test in t5510 that appears to want to\nverify this very behavior:\n\n> test_expect_success 'fetch --prune --tags does not delete the remote-tracking branches' '\n> \tcd \"$D\" &&\n> \tgit clone . prune-tags &&\n> \tcd prune-tags &&\n> \tgit fetch origin refs/heads/master:refs/tags/sometag &&\n> \n> \tgit fetch --prune --tags origin &&\n> \tgit rev-parse origin/master &&\n> \ttest_must_fail git rev-parse somebranch\n> '\n\nHowever, the last line seems to contain a copy-paste error and should\npresumably have s/somebranch/sometag/.\n\nMichael\n\n[1] It would be as if \"git clean\" had two options \"--ammonia\" and\n\"--bleach\" :-)\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"227605","messageId":"CAPc5daXvCf90WYoUWC+DxRyZEQhXGL7Bd_ZJKwfoqxeKt8TADQ@mail.gmail.com","threadId":"34923","inReplyTo":"52327E62.2040301@alum.mit.edu","subject":"Re: Local tag killer","fromName":"Junio C Hamano","fromEmail":"gitster-vger@pobox.com","sentAt":"2013-09-13T04:03:53Z","receivedAt":"2013-09-13T04:03:53Z","isPatch":false,"sender":{"key":"gitster-vger@pobox.com","avatar":null},"body":"> When looking into this, I found a test in t5510 that appears to want to\n> verify this very behavior:\n>\n>> test_expect_success 'fetch --prune --tags does not delete the remote-tracking branches' '\n\nThe title tells me that it wants to make sure when pruning tags it does\nnot touch remote-tracking branches under refs/remotes/origin/, I think.\n\n>>       cd \"$D\" &&\n>>       git clone . prune-tags &&\n>>       cd prune-tags &&\n>>       git fetch origin refs/heads/master:refs/tags/sometag &&\n>>\n>>       git fetch --prune --tags origin &&\n>>       git rev-parse origin/master &&\n>>       test_must_fail git rev-parse somebranch\n>> '\n>\n> However, the last line seems to contain a copy-paste error and should\n> presumably have s/somebranch/sometag/.\n\nI agree that somebranch must be sometag, as it wants to make sure\nthat --prune --tags removes the tag the other side does not have.\n\nI also agree that the documentation is misstated; \"remote-tracking branch\"\nmay have been a convenient and well understood phrase for whoever wrote\nthat part, but the --prune is designed to cull extra refs in the\nhierarchies into\nwhich refs would be fetched if counterparts existed on the other side, so\nculling tags that do not exist on the remote side should also be described.\n"},{"id":"227954","messageId":"xmqqd2o3p0nk.fsf@gitster.dls.corp.google.com","threadId":"34923","inReplyTo":"CAPc5daXvCf90WYoUWC+DxRyZEQhXGL7Bd_ZJKwfoqxeKt8TADQ@mail.gmail.com","subject":"Re: Local tag killer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-20T22:51:27Z","receivedAt":"2013-09-20T22:51:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster-vger@pobox.com> writes:\n\n> I also agree that the documentation is misstated; \"remote-tracking branch\"\n> may have been a convenient and well understood phrase for whoever wrote\n> that part, but the --prune is designed to cull extra refs in the\n> hierarchies into\n> which refs would be fetched if counterparts existed on the other side, so\n> culling tags that do not exist on the remote side should also be described.\n\n(gleaning-leftovers mode)\n\n\n Documentation/fetch-options.txt | 16 ++++++++++++++--\n 1 file changed, 14 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex ba1fe49..a6c581b 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -41,8 +41,20 @@ ifndef::git-pull[]\n \n -p::\n --prune::\n-\tAfter fetching, remove any remote-tracking branches which\n-\tno longer exist\ton the remote.\n+\n+\tAfter fetching, remove any local ref that was not updated\n+\tonly because the remote ref that was supposed to update it\n+\twas missing.\n++\n+For example, `git fetch origin refs/heads/*:refs/remotes/origin/*`\n+tries to update local `refs/remotes/origin/frotz` if `origin` has\n+`refs/heads/frotz`.  With this option, `refs/remotes/origin/frotz`\n+will be removed from our repository if `origin` does not have\n+`refs/heads/frotz`.\n++\n+This is used to remove remote-tracking branches which no longer\n+exist on the remote.\n+\n endif::git-pull[]\n \n ifdef::git-pull[]\n"},{"id":"227962","messageId":"523D3FD2.4090002@alum.mit.edu","threadId":"34923","inReplyTo":"xmqqd2o3p0nk.fsf@gitster.dls.corp.google.com","subject":"Re: Local tag killer","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-09-21T06:42:26Z","receivedAt":"2013-09-21T06:42:26Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 09/21/2013 12:51 AM, Junio C Hamano wrote:\n> Junio C Hamano <gitster-vger@pobox.com> writes:\n> \n>> I also agree that the documentation is misstated; \"remote-tracking branch\"\n>> may have been a convenient and well understood phrase for whoever wrote\n>> that part, but the --prune is designed to cull extra refs in the\n>> hierarchies into\n>> which refs would be fetched if counterparts existed on the other side, so\n>> culling tags that do not exist on the remote side should also be described.\n> \n> (gleaning-leftovers mode)\n\nThanks for following up on this with your proposed documentation patch.\n I have been researching and experimenting, and still find the use of\nfetch confusing with respect to tags.  I think the problem is primarily\nthat the behavior is awkward, and that it would be better to change the\nbehavior than to document the awkward behavior.\n\nI must have read an old version of the documentation, from which it\nseemed that \"git fetch --tags\" fetches all tags from the remote *in\naddition to* the references and tags that would otherwise be fetched.\nThis seems like a handy and safe feature, and I wish that this were\nindeed the effect of \"--tags\".\n\nBut I see that the documentation for \"--tags\" has been changed and now\nstates explicitly that \"--tags\" is equivalent to specifying\n\"refs/tags/*:refs/tags/*\" on the command line, overriding any configured\nrefspecs.  This doesn't seem like useful behavior; why would I want to\nfetch tags from a remote without also updating the configured refspecs?\n And contrariwise, how can I fetch the configured refspecs *and* all\ntags at the same time in a single fetch?\n\nOK, one way to do it is to configure an explicit refspec for fetching\nthe tags:\n\n[remote \"origin\"]\n\turl = [...]\n\tfetch = +refs/heads/*:refs/remotes/origin/*\n\tfetch = refs/tags/*:refs/tags/*\n\n[Here is one oddity: even if the tags refspec doesn't have a \"+\" prefix,\n\"git fetch\" will do non-ff updates to tags, presumably because of the\nimplicit tag-fetching behavior.]\n\nBut if I use this configuration and type \"git fetch --prune\", then any\nlocal tags that are not present on the remote will be killed.\n\nIn short, when local tags are in use, or tags that are in one remote but\nnot another [1], then the current Git implementation makes it impossible to\n\n- Configure \"fetch.prune\" or \"remote.$REMOTE.prune\" without preventing\nthe use of \"fetch --tags\"\n\n- Configure default fetching of all tags (via a refspec or via\nremote.$REMOTE.tagopt) without preventing the use of \"fetch --prune\"\n\n- Configure \"fetch.prune\" or \"remote.$REMOTE.prune\" and the default\nfetching of all tags (via a refspec or via remote.$REMOTE.tagopt) at the\nsame time.\n\nThis is unfortunate.\n\nI think it would be preferable if \"--prune\" would *not* affect tags, and\nif there were an extra option like \"--prune-tags\" that would have to be\nused explicitly to cause tags to be pruned.  Would somebody object to\nsuch a change?\n\nMichael\n\n[1] In fact, the scenario that bit my colleague was as follows: he had\njust built a software release, which creates a new commit and a release\ntag.  When he tried to push the commit, there was a non-ff failure due\nto an upstream change.  So he ran \"git fetch --prune\" to get the\nupstream change, and this caused the release tag (which hadn't been\npushed yet) to be lost.\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"227966","messageId":"CAEBDL5UVZERxHF5FwR66HummgjoczWGwzXwiHZtFKZGBLt6c+A@mail.gmail.com","threadId":"34923","inReplyTo":"523D3FD2.4090002@alum.mit.edu","subject":"Re: Local tag killer","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-09-21T12:28:13Z","receivedAt":"2013-09-21T12:28:13Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Sat, Sep 21, 2013 at 2:42 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> On 09/21/2013 12:51 AM, Junio C Hamano wrote:\n>> Junio C Hamano <gitster-vger@pobox.com> writes:\n>>\n>>> I also agree that the documentation is misstated; \"remote-tracking branch\"\n>>> may have been a convenient and well understood phrase for whoever wrote\n>>> that part, but the --prune is designed to cull extra refs in the\n>>> hierarchies into\n>>> which refs would be fetched if counterparts existed on the other side, so\n>>> culling tags that do not exist on the remote side should also be described.\n>>\n>> (gleaning-leftovers mode)\n>\n> Thanks for following up on this with your proposed documentation patch.\n>  I have been researching and experimenting, and still find the use of\n> fetch confusing with respect to tags.  I think the problem is primarily\n> that the behavior is awkward, and that it would be better to change the\n> behavior than to document the awkward behavior.\n\nI agree with this sentiment.  I've never liked how `--tags` operates.\n\n> I must have read an old version of the documentation, from which it\n> seemed that \"git fetch --tags\" fetches all tags from the remote *in\n> addition to* the references and tags that would otherwise be fetched.\n> This seems like a handy and safe feature, and I wish that this were\n> indeed the effect of \"--tags\".\n\nMe too.\n\n> But I see that the documentation for \"--tags\" has been changed and now\n> states explicitly that \"--tags\" is equivalent to specifying\n> \"refs/tags/*:refs/tags/*\" on the command line, overriding any configured\n> refspecs.  This doesn't seem like useful behavior; why would I want to\n> fetch tags from a remote without also updating the configured refspecs?\n>  And contrariwise, how can I fetch the configured refspecs *and* all\n> tags at the same time in a single fetch?\n>\n> OK, one way to do it is to configure an explicit refspec for fetching\n> the tags:\n>\n> [remote \"origin\"]\n>         url = [...]\n>         fetch = +refs/heads/*:refs/remotes/origin/*\n>         fetch = refs/tags/*:refs/tags/*\n>\n> [Here is one oddity: even if the tags refspec doesn't have a \"+\" prefix,\n> \"git fetch\" will do non-ff updates to tags, presumably because of the\n> implicit tag-fetching behavior.]\n>\n> But if I use this configuration and type \"git fetch --prune\", then any\n> local tags that are not present on the remote will be killed.\n>\n> In short, when local tags are in use, or tags that are in one remote but\n> not another [1], then the current Git implementation makes it impossible to\n>\n> - Configure \"fetch.prune\" or \"remote.$REMOTE.prune\" without preventing\n> the use of \"fetch --tags\"\n>\n> - Configure default fetching of all tags (via a refspec or via\n> remote.$REMOTE.tagopt) without preventing the use of \"fetch --prune\"\n>\n> - Configure \"fetch.prune\" or \"remote.$REMOTE.prune\" and the default\n> fetching of all tags (via a refspec or via remote.$REMOTE.tagopt) at the\n> same time.\n>\n> This is unfortunate.\n>\n> I think it would be preferable if \"--prune\" would *not* affect tags, and\n> if there were an extra option like \"--prune-tags\" that would have to be\n> used explicitly to cause tags to be pruned.  Would somebody object to\n> such a change?\n\nI, personally, think what you outline makes more sense.  Also, I'm\ncurious if `git remote update -p $REMOTE` suffers from the same\nproblem, if the remote was added with the `--tags` option.\n\n-John\n"},{"id":"228143","messageId":"20130924075119.GD7257@sigill.intra.peff.net","threadId":"34923","inReplyTo":"523D3FD2.4090002@alum.mit.edu","subject":"Re: Local tag killer","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-24T07:51:19Z","receivedAt":"2013-09-24T07:51:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:\n\n> I think it would be preferable if \"--prune\" would *not* affect tags, and\n> if there were an extra option like \"--prune-tags\" that would have to be\n> used explicitly to cause tags to be pruned.  Would somebody object to\n> such a change?\n\nI think most of this problem is the way that we fetch tags straight into\nthe refs/tags hierarchy. You would not do:\n\n  [remote \"origin\"]\n  fetch = +refs/heads/*:refs/heads/*\n  prune = true\n\nunless you wanted to be a pure-mirror, because you would hose your local\nchanges any time you fetched. But that is _exactly_ what we do with a\nrefs/tags/*:refs/tags/* fetch.\n\nIf we instead moved to a default fetch refspec more like:\n\n  [remote \"origin\"]\n  fetch = +refs/*:refs/remotes/origin/refs/*\n\nThen everything would Just Work. If you prune what the other side has\nlocally, that's fine. All you're doing is pruning your view of what he\nhas, not anything you've done locally.\n\nThe tricky part is tweaking the lookup rules so that \"origin/master\"\nstill works, and that looking for \"v1.0\" checks both refs/tags and\nrefs/remotes/*/refs/tags. And of course managing backwards\ncompatibility. :)\n\nIn the meantime, I'd almost be tempted to say that \"--prune\" should\nrefuse to work when we are touching anything outside of refs/remotes/.\nBut that would make true mirrors fail, who do want to munge their local\nrefs/heads/. You'd need some way to say \"no, really, it's OK to prune\".\nMaybe let remote.*.prune be \"remotes\", \"always\", or \"none\", and \"true\"\nmaps to \"remotes\"? That's not backwards compatible, but it would be much\nsafer.\n\n-Peff\n"},{"id":"228162","messageId":"52419218.3020902@xiplink.com","threadId":"34923","inReplyTo":"20130924075119.GD7257@sigill.intra.peff.net","subject":"Re: Local tag killer","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2013-09-24T13:22:32Z","receivedAt":"2013-09-24T13:22:32Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 13-09-24 03:51 AM, Jeff King wrote:\n> On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:\n>\n>> I think it would be preferable if \"--prune\" would *not* affect tags, and\n>> if there were an extra option like \"--prune-tags\" that would have to be\n>> used explicitly to cause tags to be pruned.  Would somebody object to\n>> such a change?\n>\n> I think most of this problem is the way that we fetch tags straight into\n> the refs/tags hierarchy. You would not do:\n>\n>    [remote \"origin\"]\n>    fetch = +refs/heads/*:refs/heads/*\n>    prune = true\n>\n> unless you wanted to be a pure-mirror, because you would hose your local\n> changes any time you fetched. But that is _exactly_ what we do with a\n> refs/tags/*:refs/tags/* fetch.\n>\n> If we instead moved to a default fetch refspec more like:\n>\n>    [remote \"origin\"]\n>    fetch = +refs/*:refs/remotes/origin/refs/*\n\nI'm all for such a change.\n\nYou no doubt recall the lengthy discussion about remote ref namespaces \nback in 2011 [1].  That arose while planning for 1.8, but my feeble \nrecollection is that the change was considered too disruptive.  It seems \n2.0 would be a better home for such work.\n\n\t\tM.\n\n[1] \nhttp://thread.gmane.org/gmane.comp.version-control.git/165799/focus=166729\n"},{"id":"228195","messageId":"20130925082251.GB23238@sigill.intra.peff.net","threadId":"34923","inReplyTo":"52419218.3020902@xiplink.com","subject":"Re: Local tag killer","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-25T08:22:52Z","receivedAt":"2013-09-25T08:22:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 24, 2013 at 09:22:32AM -0400, Marc Branchaud wrote:\n\n> >If we instead moved to a default fetch refspec more like:\n> >\n> >   [remote \"origin\"]\n> >   fetch = +refs/*:refs/remotes/origin/refs/*\n> \n> I'm all for such a change.\n> \n> You no doubt recall the lengthy discussion about remote ref\n> namespaces back in 2011 [1].  That arose while planning for 1.8, but\n> my feeble recollection is that the change was considered too\n> disruptive.  It seems 2.0 would be a better home for such work.\n\nI do recall the discussion, though I did not review all of the\ncomplications before writing this most recent mail.\n\nI assume there are backwards compatibility issues lurking, and we may\neven need a config switch to flip between old-style and new-style modes\n(and leave it set to old-style at first, wait a while for people to have\na git that understands both, and then flip the default to new-style).\n\nHowever, none of that is for Git 2.0. I do not think we have an exact\ndate set for Git 2.0, but we already have several switches ready to be\nflipped.  I think Junio's plan was to do it sooner rather than later,\nand not try to cram a bunch of last-minute compatibility breakages in.\n\n-Peff\n"},{"id":"228237","messageId":"alpine.LFD.2.03.1309251834210.312@syhkavp.arg","threadId":"34923","inReplyTo":"20130924075119.GD7257@sigill.intra.peff.net","subject":"Re: Local tag killer","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2013-09-25T22:54:10Z","receivedAt":"2013-09-25T22:54:10Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 24 Sep 2013, Jeff King wrote:\n\n> On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:\n> \n> > I think it would be preferable if \"--prune\" would *not* affect tags, and\n> > if there were an extra option like \"--prune-tags\" that would have to be\n> > used explicitly to cause tags to be pruned.  Would somebody object to\n> > such a change?\n> \n> I think most of this problem is the way that we fetch tags straight into\n> the refs/tags hierarchy. You would not do:\n> \n>   [remote \"origin\"]\n>   fetch = +refs/heads/*:refs/heads/*\n>   prune = true\n> \n> unless you wanted to be a pure-mirror, because you would hose your local\n> changes any time you fetched. But that is _exactly_ what we do with a\n> refs/tags/*:refs/tags/* fetch.\n> \n> If we instead moved to a default fetch refspec more like:\n> \n>   [remote \"origin\"]\n>   fetch = +refs/*:refs/remotes/origin/refs/*\n> \n> Then everything would Just Work. If you prune what the other side has\n> locally, that's fine. All you're doing is pruning your view of what he\n> has, not anything you've done locally.\n> \n> The tricky part is tweaking the lookup rules so that \"origin/master\"\n> still works, and that looking for \"v1.0\" checks both refs/tags and\n> refs/remotes/*/refs/tags. And of course managing backwards\n> compatibility. :)\n\nCheers !!!\n\nI remember participating to a discussion about this like 2.5 years ago:\n\nhttp://news.gmane.org/group/gmane.comp.version-control.git/thread=165799\n\nThe flat tag namespace remains my major annoyance with git IMHO.\n\n\nNicolas\n"},{"id":"228359","messageId":"5246C975.1050504@alum.mit.edu","threadId":"34923","inReplyTo":"alpine.LFD.2.03.1309251834210.312@syhkavp.arg","subject":"Re: Local tag killer","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-09-28T12:20:05Z","receivedAt":"2013-09-28T12:20:05Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 09/26/2013 12:54 AM, Nicolas Pitre wrote:\n> On Tue, 24 Sep 2013, Jeff King wrote:\n>> I think most of this problem is the way that we fetch tags straight into\n>> the refs/tags hierarchy. You would not do:\n>>\n>>   [remote \"origin\"]\n>>   fetch = +refs/heads/*:refs/heads/*\n>>   prune = true\n>>\n>> unless you wanted to be a pure-mirror, because you would hose your local\n>> changes any time you fetched. But that is _exactly_ what we do with a\n>> refs/tags/*:refs/tags/* fetch.\n>>\n>> If we instead moved to a default fetch refspec more like:\n>>\n>>   [remote \"origin\"]\n>>   fetch = +refs/*:refs/remotes/origin/refs/*\n>>\n>> Then everything would Just Work. [...]\n> \n> I remember participating to a discussion about this like 2.5 years ago:\n> \n> http://news.gmane.org/group/gmane.comp.version-control.git/thread=165799\n> \n> The flat tag namespace remains my major annoyance with git IMHO.\n\nI just reviewed that old thread to determine its relevance to the\npresent discussion.  For the benefit of the other readers, here is a\nsummary of the main points that I got out of it.\n\nThe main proposal under discussion was that of Johan Herland:\n\n    http://article.gmane.org/gmane.comp.version-control.git/165885\n\nNicolas made the two best arguments for the necessity of\nseparate tag namespaces per remote in *some* form:\n\n> The extraordinary misfeature of the tag namespace at the moment\n> comes from the fact that whenever you add a remote repo to fetch,\n> and do fetch it, then your flat tag namespace gets polluted with all\n> the tags the remote might have.  If you decide to delete some of\n> those remote branches, the tags that came with it are still there\n> and indistinguishable from other tags making it a real pain to sort\n> out.\n>\n> -- http://article.gmane.org/gmane.comp.version-control.git/166108\n\nand\n\n> Let's take the OpenOffice vs LibreOffice as an example.  What if I\n> want both in my repository so I can easily perform diffs between\n> those independent branches?  They may certainly end up producing\n> releases with the same version numbers (same tag name) but different\n> content (different tag references).\n>\n> -- http://article.gmane.org/gmane.comp.version-control.git/166749\n\nOther discussion and open issues regarding a ref namespace reorg:\n\n* What exactly would be the ambiguity rules for references with the same\n  name that appear in multiple remotes' namespaces?\n\n  * Are references to two annotated tags considered the same if they\n    refer to the same SHA-1, even if the annotated tags are different?\n    What about an annotated vs an unannotated tag?  The consensus\n    seemed to be \"no\".\n\n  * Do they depend on how the reference is being used?  Yes, sometimes\n    only a SHA-1 is needed, in which case multiple agreeing references\n    shouldn't be a problem.  Other times the DWIM caller needs the\n    full refname (e.g., \"git push\" pushes to different locations\n    depending on whether the source is a branch or tag), in which case\n    the rules would have to be more nuanced.\n\n  * Should the same ambiguity rules be applied to other references\n    (e.g., branches)?\n\n  * What if a branch and a tag have the same name?\n\n    * Nicolas Pitre suggested that usually they should be accepted if\n      they have the same value, and if the refname matters then the\n      branch should take precedence (with a warning).\n\n    * Peff pointed out that currently dwim_ref prefers tags, but that\n      Junio has said that that behavior was arbitrary [and by\n      implication could be changed].  He suggested:\n\n      > For dwim_ref, it prefers the tag and issues a warning. For\n      > git-push, it complains about the ambiguity and dies. For git\n      > checkout, we prefer the head. For git-tag, we prefer the tag\n      > (though I think that only matters for \"git tag -d\").\n      >\n      > -- http://article.gmane.org/gmane.comp.version-control.git/166290\n\n* What should \"name-rev\", \"describe\", \"--decorate\" output?  See\n  discussion here:\n\n      http://article.gmane.org/gmane.comp.version-control.git/165911\n\n* \"fetch\" should probably warn if it ends up fetching a tag with the\n  same name (according to the refname disambiguation rules) but value\n  that conflicts with an existing tag in a different namespace.\n\n* Do we need some pathspec modifier (e.g., \"~\") to specify that the\n  corresponding references should be auto-followed in the manner\n  currently done for refs/tags/*?  Or is auto-following maybe not\n  needed at all anymore?:\n\n      http://article.gmane.org/gmane.comp.version-control.git/160726\n\n  Junio thought, and Johan agreed, that tag auto-following should still\n  be done for repositories that use the old ref namespace format.  But\n  perhaps this could be special-cased via a config setting rather than\n  built into the refspec syntax.\n\n* How would somebody (e.g., an interim maintainer) suck down tags from\n  a project into his own refs/tags/* namespace?  (Would it even be\n  necessary?)  Should there be a tool for this?  [It seems to me that\n  something like\n\n      git fetch . refs/remotes/origin/tags/*:refs/tags/*\n\n  would do the trick, as long as pruning were turned off.]\n\n* What special handling (if any) is required for\n  refs/remotes/$REMOTE/HEAD?\n\n  * According to Junio, HEAD is meant to indicate which branch is the\n    \"main\" branch of the remote.  It is not transferred via the\n    protocol, but rather guessed at by the client's \"clone\" process:\n\n        http://article.gmane.org/gmane.comp.version-control.git/166694\n        http://article.gmane.org/gmane.comp.version-control.git/166740\n\n* How would this help somebody who wants to fetch content from multiple\n  projects (e.g., git, gitk, gitgui) into a single repo?  There might\n  be tags with the same names but very different meanings, and it would\n  be awkward if there were ambiguity warnings all over the place.\n  [Would it work to configure the fetching repo something like\n\n  [remote \"gitk-origin\"]\n          fetch = refs/tags/*:refs/remotes/gitk-origin/tags/gitk/*\n\n  and to refer to a hypothetical gitk tag \"v1.2.3\" as \"gitk/1.2.3\"?\n  Admittedly this is somewhat ambiguous with the proposed DWIM pattern\n  <REMOTE>/<TAGNAME>.]\n\n* It might be nice to have a command like\n\n      git push $REMOTE --interactive\n\n  that allows the user to choose interactively which branches/tags to\n  push\n\n  -- http://article.gmane.org/gmane.comp.version-control.git/166700\n\nI hope that saves somebody the time of reading the whole thread\n(though admittedly my summary is not especially short either).\n\n\nAs far as I can tell, the division of tags into remote-specific\nnamespaces would be another way of preventing the problem of tags being\npruned too aggressively.  But given that such a big change would be a\nhuge development effort, implementing something like the following\nmight be a quicker fix and would not conflict with a hypothetical\nfuture ref namespace reorganization:\n\n1. Limit \"git fetch --prune\" to only pruning references that are under\n   refs/remotes/*\n\n2. Add a new option --prune-tags that removes the above limitation\n\n3. And the above two changes would make this one possible: Change the\n   meaning of the --tags option to mean \"fetch all tags *in addition\n   to* (rather than *instead of*) the references that would otherwise\n   be fetched\".\n\nComments?\n\n@Johan, I know that you were working on the ref-namespace issue at\nGitMerge.  Did your work get anywhere?  Are you still working on it?\nHave you documented somewhere any new insights that you have gained\nabout the problem space?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"228365","messageId":"CALKQrgeJn1J4ntE_2Lr7Et+Oao=vB1FE6nLfaFJOvLHJLzG9tA@mail.gmail.com","threadId":"34923","inReplyTo":"5246C975.1050504@alum.mit.edu","subject":"Re: Local tag killer","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2013-09-28T21:42:59Z","receivedAt":"2013-09-28T21:42:59Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> I just reviewed that old thread to determine its relevance to the\n> present discussion.  For the benefit of the other readers, here is a\n> summary of the main points that I got out of it.\n\nI want to thank you immensely for the summary below. It really helps me\nclear my own thoughts on this topic, and is an excellent base for\ndiscussing how to advance on it.\n\n> The main proposal under discussion was that of Johan Herland:\n>\n>     http://article.gmane.org/gmane.comp.version-control.git/165885\n>\n> Nicolas made the two best arguments for the necessity of\n> separate tag namespaces per remote in *some* form:\n>\n>> The extraordinary misfeature of the tag namespace at the moment\n>> comes from the fact that whenever you add a remote repo to fetch,\n>> and do fetch it, then your flat tag namespace gets polluted with all\n>> the tags the remote might have.  If you decide to delete some of\n>> those remote branches, the tags that came with it are still there\n>> and indistinguishable from other tags making it a real pain to sort\n>> out.\n>>\n>> -- http://article.gmane.org/gmane.comp.version-control.git/166108\n>\n> and\n>\n>> Let's take the OpenOffice vs LibreOffice as an example.  What if I\n>> want both in my repository so I can easily perform diffs between\n>> those independent branches?  They may certainly end up producing\n>> releases with the same version numbers (same tag name) but different\n>> content (different tag references).\n>>\n>> -- http://article.gmane.org/gmane.comp.version-control.git/166749\n\nI'd also like to mention my initial motivation for the proposal: a\nnatural way to organize other types of remote refs (notes, replace\nrefs, etc.). The separate tag namespace came about as a natural\n(and IMHO quite useful) consequence of the proposed reorganization\nof refs/remotes/*.\n\n> Other discussion and open issues regarding a ref namespace reorg:\n>\n> * What exactly would be the ambiguity rules for references with the same\n>   name that appear in multiple remotes' namespaces?\n>\n>   * Are references to two annotated tags considered the same if they\n>     refer to the same SHA-1, even if the annotated tags are different?\n>     What about an annotated vs an unannotated tag?  The consensus\n>     seemed to be \"no\".\n>\n>   * Do they depend on how the reference is being used?  Yes, sometimes\n>     only a SHA-1 is needed, in which case multiple agreeing references\n>     shouldn't be a problem.  Other times the DWIM caller needs the\n>     full refname (e.g., \"git push\" pushes to different locations\n>     depending on whether the source is a branch or tag), in which case\n>     the rules would have to be more nuanced.\n\nCould we try to classify all ref lookups as either ref _name_ lookups\n(in which case only a single, matching full refname is acceptable), or\nref _value_ lookups (in which case multiple matching names are allowed,\nas long as they all point to the same SHA-1)? There are some complicated\ncases (e.g. describe) which needs more thought, but if we can agree on\na mechanism for dealing with all the simpler cases, that might help\ninform how to deal with the complicated ones.\n\n>   * Should the same ambiguity rules be applied to other references\n>     (e.g., branches)?\n\nIMHO, yes.\n\n>   * What if a branch and a tag have the same name?\n\nIMHO, it depends on the context of the lookup. Some commands (e.g.\nbranch, tag) are clearly only interested in one ref type, and should\nnot care about other ref types at all.\n\nFor other lookups (e.g. rev-list, rev-parse), IMHO it depends on\nwhether they're looking up ref _names_ or ref _values_. In the former\ncase, ambiguity is always an error, while in the latter case it's not,\nprovided they agree on the SHA-1 (although maybe warning about\nambiguity might be appropriate in some contexts).\n\n>     * Nicolas Pitre suggested that usually they should be accepted if\n>       they have the same value, and if the refname matters then the\n>       branch should take precedence (with a warning).\n>\n>     * Peff pointed out that currently dwim_ref prefers tags, but that\n>       Junio has said that that behavior was arbitrary [and by\n>       implication could be changed].  He suggested:\n>\n>       > For dwim_ref, it prefers the tag and issues a warning. For\n>       > git-push, it complains about the ambiguity and dies. For git\n>       > checkout, we prefer the head. For git-tag, we prefer the tag\n>       > (though I think that only matters for \"git tag -d\").\n>       >\n>       > -- http://article.gmane.org/gmane.comp.version-control.git/166290\n>\n> * What should \"name-rev\", \"describe\", \"--decorate\" output?  See\n>   discussion here:\n>\n>       http://article.gmane.org/gmane.comp.version-control.git/165911\n\nAFAICS, \"name-rev\" and \"--decorate\" are the simple cases: Use the\nshortest possible name which is still completely unambiguous in the\ncurrent repo.\n\nFor \"describe\", we want to use a tag name with no prefix (i.e. only\n\"$tag\", not \"$remote/$tag\" or \"$remote/tags/$tag\" etc.). We also\nprobably want to prefer tags from some remotes over tags from other\nremotes. Maybe something like:\n\n  git describe --tags-from $remote\n\nwhere the default behavior (i.e. given no --tags-from) would be to\nassume\n\n  --tags-from $(branch.$current.remote)\n  --tags-from origin\n  --tags-from . # local tags\n\nor some combination of those.\n\n> * \"fetch\" should probably warn if it ends up fetching a tag with the\n>   same name (according to the refname disambiguation rules) but value\n>   that conflicts with an existing tag in a different namespace.\n>\n> * Do we need some pathspec modifier (e.g., \"~\") to specify that the\n>   corresponding references should be auto-followed in the manner\n>   currently done for refs/tags/*?  Or is auto-following maybe not\n>   needed at all anymore?:\n>\n>       http://article.gmane.org/gmane.comp.version-control.git/160726\n>\n>   Junio thought, and Johan agreed, that tag auto-following should still\n>   be done for repositories that use the old ref namespace format.  But\n>   perhaps this could be special-cased via a config setting rather than\n>   built into the refspec syntax.\n\nWhen using separate remote tag namespaces, I believe tag auto-following\nis no longer needed. Instead the default refspec would simply fetch all\ntags into the remote tag namespace.\n\nAs for the config setting, I have thought much about whether it is\npossible to introduce remote ref namespaces while retaining backwards\ncompatibility, all _without_ having an explicit config switch. However,\nI have more or less arrived at the conclusion that a \"clean break\" with\na config switch that selects either old or new ref layouts (and\nassociated semantics/behavior) is preferable.\n\n> * How would somebody (e.g., an interim maintainer) suck down tags from\n>   a project into his own refs/tags/* namespace?  (Would it even be\n>   necessary?)\n\nI'm not convinced it would be necessary. I have yet to see a case where\na (suitably unambiguous) remote tag would not fulfill the same purpose\nas the equivalent local tag. The only exception is for dealing with\nambiguous remote tags, where a local tag could be created to serve as a\ntie-breaker.\n\n>   Should there be a tool for this?  [It seems to me that something like\n>\n>       git fetch . refs/remotes/origin/tags/*:refs/tags/*\n>\n>   would do the trick, as long as pruning were turned off.]\n\nAFAICS, that fetch command should work (and should IMHO be unaffected\nby fetch.prune or remote.$remote.prune in the configuration).\n\n> * What special handling (if any) is required for\n>   refs/remotes/$REMOTE/HEAD?\n>\n>   * According to Junio, HEAD is meant to indicate which branch is the\n>     \"main\" branch of the remote.  It is not transferred via the\n>     protocol, but rather guessed at by the client's \"clone\" process:\n>\n>         http://article.gmane.org/gmane.comp.version-control.git/166694\n>         http://article.gmane.org/gmane.comp.version-control.git/166740\n\nIMHO, if we want HEAD to accurately represent the \"main\" branch of the\nremote, then we must also extend the protocol to contain it, so that it\ndoes not go stale or suffer at the mercy of \"guesswork\".\n\n> * How would this help somebody who wants to fetch content from multiple\n>   projects (e.g., git, gitk, gitgui) into a single repo?  There might\n>   be tags with the same names but very different meanings, and it would\n>   be awkward if there were ambiguity warnings all over the place.\n>   [Would it work to configure the fetching repo something like\n>\n>   [remote \"gitk-origin\"]\n>           fetch = refs/tags/*:refs/remotes/gitk-origin/tags/gitk/*\n>\n>   and to refer to a hypothetical gitk tag \"v1.2.3\" as \"gitk/1.2.3\"?\n>   Admittedly this is somewhat ambiguous with the proposed DWIM pattern\n>   <REMOTE>/<TAGNAME>.]\n\nOnly if you also had a remote called \"gitk\". ;)\n\nAn alternative way to solve the problem of many ambiguity warnings:\nIf we define the rules so that local tags always override remote tags,\nyou could simply fetch the tags from your preferred remote into your\nlocal tag namespace (as discussed above).\n\nPersonally, I would rather set up the configuration like this:\n\n  [remote \"gitk\"]\n          fetch = refs/tags/*:refs/remotes/gitk/tags/*\n\n(i.e. keeping the default refspec) and then use \"gitk/v1.2.3\",\n\"git/v.1.2.3\", \"gitgui/v1.2.3\" to disambiguate between the tags.\n\n> * It might be nice to have a command like\n>\n>       git push $REMOTE --interactive\n>\n>   that allows the user to choose interactively which branches/tags to\n>   push\n>\n>   -- http://article.gmane.org/gmane.comp.version-control.git/166700\n\nI like that idea, but I think it's somewhat peripheral to the ref\nnamespace discussion.\n\n> I hope that saves somebody the time of reading the whole thread\n> (though admittedly my summary is not especially short either).\n>\n>\n> As far as I can tell, the division of tags into remote-specific\n> namespaces would be another way of preventing the problem of tags being\n> pruned too aggressively.  But given that such a big change would be a\n> huge development effort, implementing something like the following\n> might be a quicker fix and would not conflict with a hypothetical\n> future ref namespace reorganization:\n>\n> 1. Limit \"git fetch --prune\" to only pruning references that are under\n>    refs/remotes/*\n>\n> 2. Add a new option --prune-tags that removes the above limitation\n>\n> 3. And the above two changes would make this one possible: Change the\n>    meaning of the --tags option to mean \"fetch all tags *in addition\n>    to* (rather than *instead of*) the references that would otherwise\n>    be fetched\".\n\nAgreed. The ref namespace topic clearly dwarfs the issue that started\nthis thread.\n\n> @Johan, I know that you were working on the ref-namespace issue at\n> GitMerge.  Did your work get anywhere? Are you still working on it?\n\nI posted a couple of patch series dealing with _some_ preliminary\nissues and adding some initial behavior changes. The first one was\nparked in 'pu':\n\n  https://git.kernel.org/cgit/git/git.git/commit/?h=pu&id=07e56ed\n\nbut has since been stuck in limbo, since we decided to roll it into\nthe larger series:\n\n  http://article.gmane.org/gmane.comp.version-control.git/225137\n\nThe larger series was last posted here:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/223981\n\nSince then, regrettably, not much has happened. I've now rebased the\nseries (still unfinished) onto v1.8.4 (no conflicts, still passes all\ntests), and pushed it to my GitHub account:\n\n  https://github.com/jherland/git/commits/peers-resurrect\n\nThat said, there are probably things in that series I'd like to revise,\ne.g. introducing the config switch controlling new vs. old behavior as\nearly as possible, and reverting back to using refs/remotes/* instead\nof refs/peers/*.\n\n> Have you documented somewhere any new insights that you have gained\n> about the problem space?\n\nI think this (hideously long) reply should cover it...\n\n\nHave fun! :)\n\n...Johan\n\n--\nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"228436","messageId":"5247ACB9.40208@alum.mit.edu","threadId":"34923","inReplyTo":"CALKQrgeJn1J4ntE_2Lr7Et+Oao=vB1FE6nLfaFJOvLHJLzG9tA@mail.gmail.com","subject":"Re: Local tag killer","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-09-29T04:29:45Z","receivedAt":"2013-09-29T04:29:45Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 09/28/2013 11:42 PM, Johan Herland wrote:\n> On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n>> [...]\n>> Nicolas made the two best arguments for the necessity of\n>> separate tag namespaces per remote in *some* form:\n>> [...]\n> \n> I'd also like to mention my initial motivation for the proposal: a\n> natural way to organize other types of remote refs (notes, replace\n> refs, etc.). The separate tag namespace came about as a natural\n> (and IMHO quite useful) consequence of the proposed reorganization\n> of refs/remotes/*.\n\nACK.\n\n>> Other discussion and open issues regarding a ref namespace reorg:\n>>\n>> * What exactly would be the ambiguity rules for references with the same\n>>   name that appear in multiple remotes' namespaces?\n>>\n>>   * Are references to two annotated tags considered the same if they\n>>     refer to the same SHA-1, even if the annotated tags are different?\n>>     What about an annotated vs an unannotated tag?  The consensus\n>>     seemed to be \"no\".\n>>\n>>   * Do they depend on how the reference is being used?  Yes, sometimes\n>>     only a SHA-1 is needed, in which case multiple agreeing references\n>>     shouldn't be a problem.  Other times the DWIM caller needs the\n>>     full refname (e.g., \"git push\" pushes to different locations\n>>     depending on whether the source is a branch or tag), in which case\n>>     the rules would have to be more nuanced.\n> \n> Could we try to classify all ref lookups as either ref _name_ lookups\n> (in which case only a single, matching full refname is acceptable), or\n> ref _value_ lookups (in which case multiple matching names are allowed,\n> as long as they all point to the same SHA-1)? There are some complicated\n> cases (e.g. describe) which needs more thought, but if we can agree on\n> a mechanism for dealing with all the simpler cases, that might help\n> inform how to deal with the complicated ones.\n\nYes, name vs. value lookups is a useful distinction.\n\n> [...]\n>> * How would somebody (e.g., an interim maintainer) suck down tags from\n>>   a project into his own refs/tags/* namespace?  (Would it even be\n>>   necessary?)\n> \n> I'm not convinced it would be necessary. I have yet to see a case where\n> a (suitably unambiguous) remote tag would not fulfill the same purpose\n> as the equivalent local tag. The only exception is for dealing with\n> ambiguous remote tags, where a local tag could be created to serve as a\n> tie-breaker.\n\nI guess I was wondering how the interim maintainer would get Junio's\ntags into his public repo (which he would want to do, so that users can\nget everything from a single clone).\n\nI think that the new version of \"git push --tags\" should *not* push all\ntags from all remotes; it should push only refs/tags, like now.  So I\nwas thinking that the interim maintainer would want to import Junio's\ntags into his own namespace, then\n\n    git push --tags $URL\n\nBut I guess it would be cleaner just to push using an explicit refspec:\n\n    git push $URL 'refs/remotes/origin/tags/*:refs/tags/*'\n\n>> [...]\n>> * How would this help somebody who wants to fetch content from multiple\n>>   projects (e.g., git, gitk, gitgui) into a single repo?  There might\n>>   be tags with the same names but very different meanings, and it would\n>>   be awkward if there were ambiguity warnings all over the place.\n>>   [Would it work to configure the fetching repo something like\n>>\n>>   [remote \"gitk-origin\"]\n>>           fetch = refs/tags/*:refs/remotes/gitk-origin/tags/gitk/*\n>>\n>>   and to refer to a hypothetical gitk tag \"v1.2.3\" as \"gitk/1.2.3\"?\n>>   Admittedly this is somewhat ambiguous with the proposed DWIM pattern\n>>   <REMOTE>/<TAGNAME>.]\n> \n> Only if you also had a remote called \"gitk\". ;)\n\nTrue.\n\n> An alternative way to solve the problem of many ambiguity warnings:\n> If we define the rules so that local tags always override remote tags,\n> you could simply fetch the tags from your preferred remote into your\n> local tag namespace (as discussed above).\n> \n> Personally, I would rather set up the configuration like this:\n> \n>   [remote \"gitk\"]\n>           fetch = refs/tags/*:refs/remotes/gitk/tags/*\n> \n> (i.e. keeping the default refspec) and then use \"gitk/v1.2.3\",\n> \"git/v.1.2.3\", \"gitgui/v1.2.3\" to disambiguate between the tags.\n\nBut if there were more than one remote providing gitk tags, it would be\ndifficult to grab a tag without caring where it came from.  And where\nwould I create a local gitk-scope tag?\n\nI wonder whether remotes.group could sensibly be used to group remotes\ninto logical groups for value lookups:\n\n    [remotes]\n            gitk = gitk-origin\n            gitk = second-gitk-repo\n\nThen DWIM could be taught to seek \"gitk/foo\" under\n\"refs/remotes/gitk-origin/tags/foo\" and\n\"refs/remotes/second-gitk-repo/tags/foo\" in addition to\n\"refs/tags/gitk/foo\" (insisting, of course, that if more than one of\nthese are present that they are all consistent).\n\nRemote groups might also be used to configure the remotes that describe\nconsiders when describing a commit:\n\n    [remotes]\n            describe = junio\n            describe = jrn\n\nor maybe (using the above config)\n\n    git describe --remote-group=gitk\n\n>> [...]\n>> @Johan, I know that you were working on the ref-namespace issue at\n>> GitMerge.  Did your work get anywhere? Are you still working on it?\n> \n> I posted [...]\n\nThanks for your comments, and for the status update!\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"228450","messageId":"CALKQrgdG3FzA=8A9TyuGGumqWJ05zYK1r2uaAOrhNaAUju-6jw@mail.gmail.com","threadId":"34923","inReplyTo":"5247ACB9.40208@alum.mit.edu","subject":"Re: Local tag killer","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2013-09-29T09:30:10Z","receivedAt":"2013-09-29T09:30:10Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sun, Sep 29, 2013 at 6:29 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> I wonder whether remotes.group could sensibly be used to group remotes\n> into logical groups for value lookups:\n>\n>     [remotes]\n>             gitk = gitk-origin\n>             gitk = second-gitk-repo\n>\n> Then DWIM could be taught to seek \"gitk/foo\" under\n> \"refs/remotes/gitk-origin/tags/foo\" and\n> \"refs/remotes/second-gitk-repo/tags/foo\" in addition to\n> \"refs/tags/gitk/foo\" (insisting, of course, that if more than one of\n> these are present that they are all consistent).\n\nThis is an interesting idea. AFAICS, remotes.<group> is currently only\nused by \"git remote update\" and \"git fetch\". According to git-remote(1)\nit's used like this:\n\n    [git remote] update\n        Fetch updates for a named set of remotes in the repository\n        as defined by remotes.<group>. If a named group is not\n        specified on the command line, the configuration parameter\n        remotes.default will be used; if remotes.default is not\n        defined, all remotes which do not have the configuration\n        parameter remote.<name>.skipDefaultUpdate set to true will\n        be updated. (See git-config(1)).\n\nI believe this would work well when extended to ref lookup as well:\n\n - Defining remotes.$group allows you to lookup refs across the grouped\n   remotes by using the \"$group/<ref>\" syntax, as you describe above.\n\n - If remotes.default is defined, ref lookup happens by default across\n   only those remotes, i.e. \"$tag\" will be sought under refs/tags/$tag\n   and then refs/remotes/$remote/tags/$tag for each $remote in\n   remotes.default.\n\n - If remotes.default is not defined, ref lookup happens across all\n   remotes. This is analogous to what happens with tags today; they\n   are all dumped into refs/tags/* and lookup considers all of them.\n\n> Remote groups might also be used to configure the remotes that describe\n> considers when describing a commit:\n>\n>     [remotes]\n>             describe = junio\n>             describe = jrn\n>\n> or maybe (using the above config)\n>\n>     git describe --remote-group=gitk\n\nHmm. I'd like to apply the same rules here, to stay consistent:\n\n - \"git describe --from=$remote1 --from=$remote2\" considers tags\n   from refs/remotes/$remote1/tags/* and refs/remotes/$remote2/tags/*\n\n - \"git describe --from=$group\" considers tags from\n   refs/remotes/$remote/tags/* for each $remote in $group\n\n - \"git describe\" considers tags from all remotes mentioned in\n   remotes.default, or _all_ remotes is remotes.default is unset.\n\nAdditionally:\n\n - \"git describe\" (without --from) also considers (and prefers?) local\n   tags.\n\n - \"git describe --from=foo\" does NOT consider local tags, but will\n   also consider them if \"--from=.\" is used.\n\n\n...Johan\n\n--\nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"228468","messageId":"52499797.9030100@xiplink.com","threadId":"34923","inReplyTo":"5247ACB9.40208@alum.mit.edu","subject":"Re: Local tag killer","fromName":"Marc Branchaud","fromEmail":"mbranchaud@xiplink.com","sentAt":"2013-09-30T15:24:07Z","receivedAt":"2013-09-30T15:24:07Z","isPatch":false,"sender":{"key":"mbranchaud@xiplink.com","avatar":null},"body":"On 13-09-29 12:29 AM, Michael Haggerty wrote:\n> On 09/28/2013 11:42 PM, Johan Herland wrote:\n>> On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n>> [...]\n>>> * How would somebody (e.g., an interim maintainer) suck down tags from\n>>>   a project into his own refs/tags/* namespace?  (Would it even be\n>>>   necessary?)\n>>\n>> I'm not convinced it would be necessary. I have yet to see a case where\n>> a (suitably unambiguous) remote tag would not fulfill the same purpose\n>> as the equivalent local tag. The only exception is for dealing with\n>> ambiguous remote tags, where a local tag could be created to serve as a\n>> tie-breaker.\n> \n> I guess I was wondering how the interim maintainer would get Junio's\n> tags into his public repo (which he would want to do, so that users can\n> get everything from a single clone).\n> \n> I think that the new version of \"git push --tags\" should *not* push all\n> tags from all remotes; it should push only refs/tags, like now.  So I\n> was thinking that the interim maintainer would want to import Junio's\n> tags into his own namespace, then\n> \n>     git push --tags $URL\n> \n> But I guess it would be cleaner just to push using an explicit refspec:\n> \n>     git push $URL 'refs/remotes/origin/tags/*:refs/tags/*'\n\n(Thanks for the awesome summary!)\n\nYou seem to be considering the case of an interim maintainer who, prior to\nbecoming the maintainer, has his own clone of the \"official\" repo and now\nwants to make his clone the \"official\" repo, perhaps only temporarily.\n\nBut what if the interim maintainer has his own tags in his clone?  What if,\nafter he is no longer the interim maintainer, he wants to remove the\n\"official\" tags from his clone's local namespace?  The interim maintainer\nmight also have his own branches in his clone, which shouldn't be part of an\n\"official\" repo.\n\nIt seems to me that an interim maintainer would be wise to simply mirror the\n\"official\" repo and publish with that mirror.  So the gymnastics you're\ncontemplating don't seem necessary to me.\n\n>>> [...]\n>>> * How would this help somebody who wants to fetch content from multiple\n>>>   projects (e.g., git, gitk, gitgui) into a single repo?  There might\n>>>   be tags with the same names but very different meanings, and it would\n>>>   be awkward if there were ambiguity warnings all over the place.\n\nWhy would there be ambiguity warnings?  The fetch command shouldn't issue any\nwarnings, since all the remotes' names get safely tucked away in distinct\nnamespaces.\n\nAre we talking about DWIM warnings?  Aside from git-describe I don't see why\nsuch warnings would be a problem.  To DWIM-resolve a tag name look in\nrefs/tags/* and refs/remotes/*/tags/* -- much like it's done for branches\nalready.  If a tag name has multiple matches then it's ambiguous.  Git could\nbe clever and check for matching SHA1 values, but why bother?  It almost\nseems like a disservice to silently disambiguate such names.  I would think a\nuser would prefer to know about any possible ambiguities, rather than have\nsome suddenly appear (and maybe also disappear).\n\nAnd as for git-describe, I think it should only consider remote namespaces\nwhen asked to via a command-line option or configuration setting (again\nfollowing the behaviour of git-branch).  Let whoever implements such an\noption define whatever disambiguation rules they like.  Although I'd suggest\nthat the first implementation be very simple so that we can learn how people\nexpect it to work.  We may just find that users don't want git-describe to\nconsider remote namespaces at all.\n\nAside from that, I guess I just don't see a problem with using the existing\nbranch name disambiguation rules.  Am I missing something?\n\n\t\tM.\n"},{"id":"228469","messageId":"alpine.LFD.2.03.1309301138200.6331@syhkavp.arg","threadId":"34923","inReplyTo":"52499797.9030100@xiplink.com","subject":"Re: Local tag killer","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2013-09-30T15:52:47Z","receivedAt":"2013-09-30T15:52:47Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 30 Sep 2013, Marc Branchaud wrote:\n\n> Why would there be ambiguity warnings?  The fetch command shouldn't issue any\n> warnings, since all the remotes' names get safely tucked away in distinct\n> namespaces.\n> \n> Are we talking about DWIM warnings?  Aside from git-describe I don't see why\n> such warnings would be a problem.  To DWIM-resolve a tag name look in\n> refs/tags/* and refs/remotes/*/tags/* -- much like it's done for branches\n> already.  If a tag name has multiple matches then it's ambiguous.  Git could\n> be clever and check for matching SHA1 values, but why bother?  It almost\n> seems like a disservice to silently disambiguate such names.  I would think a\n> user would prefer to know about any possible ambiguities, rather than have\n> some suddenly appear (and maybe also disappear).\n\nConsider that I have in my Linux kernel tree:\n\n- a remote branch corresponding to Linus' master tree\n\n- multiple remote branches corresponding to Linux stable branches\n\n- a remote for linux-next which is a repo constantly being rebased\n\nNow all those repositories share the mainline tags from Linus' repo and \nthey add some more of they own which are not shared.  So if they all \nhave a v3.11 tag that resolve to the same SHA1, then there is \neffectively no ambiguity at all and git should not warn at all.\n\n*However* if one of those v3.11 tags does not agree with the others \n_then_ I want to be warned about it.\n\nSo having multiple matching tags that do resolve to the same SHA1 across \ndifferent remote repositories _is_ the norm and should work \ntransparently.\n\n\nNicolas\n"},{"id":"228474","messageId":"5249CDF7.4050904@xiplink.com","threadId":"34923","inReplyTo":"alpine.LFD.2.03.1309301138200.6331@syhkavp.arg","subject":"Re: Local tag killer","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2013-09-30T19:16:07Z","receivedAt":"2013-09-30T19:16:07Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 13-09-30 11:52 AM, Nicolas Pitre wrote:\n> On Mon, 30 Sep 2013, Marc Branchaud wrote:\n> \n>> Why would there be ambiguity warnings?  The fetch command shouldn't issue any\n>> warnings, since all the remotes' names get safely tucked away in distinct\n>> namespaces.\n>>\n>> Are we talking about DWIM warnings?  Aside from git-describe I don't see why\n>> such warnings would be a problem.  To DWIM-resolve a tag name look in\n>> refs/tags/* and refs/remotes/*/tags/* -- much like it's done for branches\n>> already.  If a tag name has multiple matches then it's ambiguous.  Git could\n>> be clever and check for matching SHA1 values, but why bother?  It almost\n>> seems like a disservice to silently disambiguate such names.  I would think a\n>> user would prefer to know about any possible ambiguities, rather than have\n>> some suddenly appear (and maybe also disappear).\n> \n> Consider that I have in my Linux kernel tree:\n> \n> - a remote branch corresponding to Linus' master tree\n> \n> - multiple remote branches corresponding to Linux stable branches\n> \n> - a remote for linux-next which is a repo constantly being rebased\n> \n> Now all those repositories share the mainline tags from Linus' repo and \n> they add some more of they own which are not shared.  So if they all \n> have a v3.11 tag that resolve to the same SHA1, then there is \n> effectively no ambiguity at all and git should not warn at all.\n\nThanks, this example helps very much.\n\n> *However* if one of those v3.11 tags does not agree with the others \n> _then_ I want to be warned about it.\n\nHmmm.  What behaviour would you like if you also had some non-Linux remote,\nsay for some driver code or something, that also had a v3.11 tag?  I presume\nyou want commands like\n\tgit checkout -b my-topic v3.11\nto do the Right Thing, but what's the right thing for you here?\n\n> So having multiple matching tags that do resolve to the same SHA1 across \n> different remote repositories _is_ the norm and should work \n> transparently.\n\nMy suggestion for your example is that if some remote's tags are so\nimportant/useful then you're better off importing them into your local tag\nnamespace (e.g. \"git fetch Linus refs/tags/*:refs/tags/*\").  By making the\nremote's tags local, you're expressly telling git that they should be\nconsidered for DWIMery, git-describe, etc.\n\nI feel this approach lets us avoid having to somehow teach git which remote's\n\"v3.11\" tags are important enough to merit an ambiguity warning and which\naren't.  Plus you get what I think you want, which is the current behaviour.\n\nIf this works for you, maybe it gives us a way forward:  All the DWIM\nmachinery should only consider the local namespace, perhaps with options to\nexplicitly ask it to expand its search, and we leave it up to the user to\nspecify which remotes' namespaces should be imported into the local namespace?\n\n\t\tM.\n"},{"id":"228477","messageId":"alpine.LFD.2.03.1309301527270.6331@syhkavp.arg","threadId":"34923","inReplyTo":"5249CDF7.4050904@xiplink.com","subject":"Re: Local tag killer","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2013-09-30T20:08:13Z","receivedAt":"2013-09-30T20:08:13Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 30 Sep 2013, Marc Branchaud wrote:\n\n> On 13-09-30 11:52 AM, Nicolas Pitre wrote:\n> > Consider that I have in my Linux kernel tree:\n> > \n> > - a remote branch corresponding to Linus' master tree\n> > \n> > - multiple remote branches corresponding to Linux stable branches\n> > \n> > - a remote for linux-next which is a repo constantly being rebased\n> > \n> > Now all those repositories share the mainline tags from Linus' repo and \n> > they add some more of they own which are not shared.  So if they all \n> > have a v3.11 tag that resolve to the same SHA1, then there is \n> > effectively no ambiguity at all and git should not warn at all.\n> \n> Thanks, this example helps very much.\n> \n> > *However* if one of those v3.11 tags does not agree with the others \n> > _then_ I want to be warned about it.\n> \n> Hmmm.  What behaviour would you like if you also had some non-Linux remote,\n> say for some driver code or something, that also had a v3.11 tag?\n\nI want git to complain and bail out, maybe suggesting that I should use \n\"driver_something/tag/v3.11\" to disambiguate the tag.\n\n> I presume\n> you want commands like\n> \tgit checkout -b my-topic v3.11\n> to do the Right Thing, but what's the right thing for you here?\n\ngit itself can't know it.  So the best git could do is to list \nconflicting tags with the shortest path that makes them unambiguous and \nsuggest that I try again with one of them.\n\n> > So having multiple matching tags that do resolve to the same SHA1 across \n> > different remote repositories _is_ the norm and should work \n> > transparently.\n> \n> My suggestion for your example is that if some remote's tags are so\n> important/useful then you're better off importing them into your local tag\n> namespace (e.g. \"git fetch Linus refs/tags/*:refs/tags/*\").  By making the\n> remote's tags local, you're expressly telling git that they should be\n> considered for DWIMery, git-describe, etc.\n\nSure, it is probably a good thing semantically to give priority to local \ntags when they exist. However...\n\n> I feel this approach lets us avoid having to somehow teach git which remote's\n> \"v3.11\" tags are important enough to merit an ambiguity warning and which\n> aren't.  Plus you get what I think you want, which is the current behaviour.\n\nBut I disagree here.  Most people simply won't care about local tags \nsince the remote tags are sufficient for what they need.  And if they \nhave multiple remotes in their repository then it is most likely to be \ndifferent forks of the same project sharing mostly the same tags, and \nwhere those tags diverge then they're most likely to have different tag \nnames as well.  So in the large majority of the cases, this v3.11 tag \nwill come from one or more remotes and they will refer to the same SHA1, \nso it ought to just work without any special fetch.  Also, if I refer to \nv3.11.1 which is a tag that only exists in one of the remote branches \nand not in Linus' remote then it ought to just work as well.  That is \nmore inline with the current _usage_ behavior even if the flat namespace \nis otherwise a nightmare to sort out when managing remotes.\n\nFurthermore, git already has some code to detect refname ambiguities:\n\n$ git init && echo \"foo\" > foo.txt && git add foo.txt\n$ git commit -m \"foo\" && git tag foo && git branch foo && git log foo\nwarning: refname 'foo' is ambiguous.\n\nSo adding the extra step to lookup all possible tags and make sure they \nresolve to the same SHA1 should be a logical extension to what's already \nthere.\n\nAgain, in the cases where there is actually a SHA1 conflict between all \npossible tags that match a tag short-end then listing them and asking the \nuser to be more explicit is the right thing to do.  But that should be a \nvery rare case in practice, and designing for making this case easy is \nthe wrong approach.\n\nInstead, the common case of multiple remotes with duplicated tag names \nreferring to the same thing _and/or_ multiple remotes with distinct tags \nnames is what should be made easy to use with no extra steps.\n\n\nNicolas\n"},{"id":"228480","messageId":"5249E9C8.1070700@xiplink.com","threadId":"34923","inReplyTo":"alpine.LFD.2.03.1309301527270.6331@syhkavp.arg","subject":"Re: Local tag killer","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2013-09-30T21:14:48Z","receivedAt":"2013-09-30T21:14:48Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 13-09-30 04:08 PM, Nicolas Pitre wrote:\n> On Mon, 30 Sep 2013, Marc Branchaud wrote:\n> \n>> On 13-09-30 11:52 AM, Nicolas Pitre wrote:\n>>> Consider that I have in my Linux kernel tree:\n>>>\n>>> - a remote branch corresponding to Linus' master tree\n>>>\n>>> - multiple remote branches corresponding to Linux stable branches\n>>>\n>>> - a remote for linux-next which is a repo constantly being rebased\n>>>\n>>> Now all those repositories share the mainline tags from Linus' repo and \n>>> they add some more of they own which are not shared.  So if they all \n>>> have a v3.11 tag that resolve to the same SHA1, then there is \n>>> effectively no ambiguity at all and git should not warn at all.\n>>\n>> Thanks, this example helps very much.\n>>\n>>> *However* if one of those v3.11 tags does not agree with the others \n>>> _then_ I want to be warned about it.\n>>\n>> Hmmm.  What behaviour would you like if you also had some non-Linux remote,\n>> say for some driver code or something, that also had a v3.11 tag?\n> \n> I want git to complain and bail out, maybe suggesting that I should use \n> \"driver_something/tag/v3.11\" to disambiguate the tag.\n> \n>> I presume\n>> you want commands like\n>> \tgit checkout -b my-topic v3.11\n>> to do the Right Thing, but what's the right thing for you here?\n> \n> git itself can't know it.  So the best git could do is to list \n> conflicting tags with the shortest path that makes them unambiguous and \n> suggest that I try again with one of them.\n> \n>>> So having multiple matching tags that do resolve to the same SHA1 across \n>>> different remote repositories _is_ the norm and should work \n>>> transparently.\n>>\n>> My suggestion for your example is that if some remote's tags are so\n>> important/useful then you're better off importing them into your local tag\n>> namespace (e.g. \"git fetch Linus refs/tags/*:refs/tags/*\").  By making the\n>> remote's tags local, you're expressly telling git that they should be\n>> considered for DWIMery, git-describe, etc.\n> \n> Sure, it is probably a good thing semantically to give priority to local \n> tags when they exist. However...\n> \n>> I feel this approach lets us avoid having to somehow teach git which remote's\n>> \"v3.11\" tags are important enough to merit an ambiguity warning and which\n>> aren't.  Plus you get what I think you want, which is the current behaviour.\n> \n> But I disagree here.  Most people simply won't care about local tags \n> since the remote tags are sufficient for what they need.\n\nGood point -- I see where my suggestion was wrong.  I think it's worthwhile\nto make sure that bare tag names \"just work\" after a simple clone.  Git's\nDWIM code already does this for branch names, and it makes sense to extend\nthat to other ref types in remote namespaces.\n\n> And if they \n> have multiple remotes in their repository then it is most likely to be \n> different forks of the same project sharing mostly the same tags, and \n> where those tags diverge then they're most likely to have different tag \n> names as well.\n\nI disagree about the \"most likely\" part, but it's only a niggle.  I agree\nwith the overall point that disambiguation through SHA1 comparison makes sense.\n\n> So in the large majority of the cases, this v3.11 tag \n> will come from one or more remotes and they will refer to the same SHA1, \n> so it ought to just work without any special fetch.  Also, if I refer to \n> v3.11.1 which is a tag that only exists in one of the remote branches \n> and not in Linus' remote then it ought to just work as well.  That is \n> more inline with the current _usage_ behavior even if the flat namespace \n> is otherwise a nightmare to sort out when managing remotes.\n\nAgreed.\n\n> Furthermore, git already has some code to detect refname ambiguities:\n> \n> $ git init && echo \"foo\" > foo.txt && git add foo.txt\n> $ git commit -m \"foo\" && git tag foo && git branch foo && git log foo\n> warning: refname 'foo' is ambiguous.\n> \n> So adding the extra step to lookup all possible tags and make sure they \n> resolve to the same SHA1 should be a logical extension to what's already \n> there.\n> \n> Again, in the cases where there is actually a SHA1 conflict between all \n> possible tags that match a tag short-end then listing them and asking the \n> user to be more explicit is the right thing to do.  But that should be a \n> very rare case in practice, and designing for making this case easy is \n> the wrong approach.\n> \n> Instead, the common case of multiple remotes with duplicated tag names \n> referring to the same thing _and/or_ multiple remotes with distinct tags \n> names is what should be made easy to use with no extra steps.\n\nAgain, I don't think that's the common case.  I think it's just as likely for\nthere to be multiple remotes with duplicate tag names that refer to different\nobjects.  However, SHA1-disambiguation covers all these cases.\n\n\t\tM.\n"},{"id":"228486","messageId":"alpine.LFD.2.03.1309301839080.6331@syhkavp.arg","threadId":"34923","inReplyTo":"5249E9C8.1070700@xiplink.com","subject":"Re: Local tag killer","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2013-09-30T22:44:09Z","receivedAt":"2013-09-30T22:44:09Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 30 Sep 2013, Marc Branchaud wrote:\n\n> On 13-09-30 04:08 PM, Nicolas Pitre wrote:\n> > Again, in the cases where there is actually a SHA1 conflict between all \n> > possible tags that match a tag short-end then listing them and asking the \n> > user to be more explicit is the right thing to do.  But that should be a \n> > very rare case in practice, and designing for making this case easy is \n> > the wrong approach.\n> > \n> > Instead, the common case of multiple remotes with duplicated tag names \n> > referring to the same thing _and/or_ multiple remotes with distinct tags \n> > names is what should be made easy to use with no extra steps.\n> \n> Again, I don't think that's the common case.  I think it's just as likely for\n> there to be multiple remotes with duplicate tag names that refer to different\n> objects.\n\nWhy do you say so?  I'm curious to know what kind of work flow would do \nthat in practice.\n\nAt least for typical Linux kernel workflows what I said above is true.\n\n\nNicolas\n"},{"id":"228488","messageId":"20130930231803.GA23218@sigill.intra.peff.net","threadId":"34923","inReplyTo":"alpine.LFD.2.03.1309301839080.6331@syhkavp.arg","subject":"Re: Local tag killer","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-30T23:18:03Z","receivedAt":"2013-09-30T23:18:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 30, 2013 at 06:44:09PM -0400, Nicolas Pitre wrote:\n\n> > Again, I don't think that's the common case.  I think it's just as likely for\n> > there to be multiple remotes with duplicate tag names that refer to different\n> > objects.\n> \n> Why do you say so?  I'm curious to know what kind of work flow would do \n> that in practice.\n> \n> At least for typical Linux kernel workflows what I said above is true.\n\nI could image if you are fetching from a bunch of coworkers that several\npeople might reuse a common name like \"start\" or \"tmp\" for different\npurposes.\n\nBut I think the behavior you've described handles that quite naturally.\nIf there is one \"start\", or if they all match, it is unambiguous. If\nthere are multiple matches, git says \"which one did you mean?\" and you\ncan say \"bob/start\" or \"alice/start\" to disambiguate. Anything else\nwould be a guess.\n\nIf _you_ have a refs/tags/start, then I think that should unambiguously\ntake precedence over that of your coworkers. That way your coworkers\ncannot pollute the lookup of items in your own namespace.\n\n-Peff\n"},{"id":"228491","messageId":"524A3BB6.9060808@xiplink.com","threadId":"34923","inReplyTo":"alpine.LFD.2.03.1309301839080.6331@syhkavp.arg","subject":"Re: Local tag killer","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2013-10-01T03:04:22Z","receivedAt":"2013-10-01T03:04:22Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 13-09-30 06:44 PM, Nicolas Pitre wrote:\n> On Mon, 30 Sep 2013, Marc Branchaud wrote:\n>\n>> On 13-09-30 04:08 PM, Nicolas Pitre wrote:\n>>> Again, in the cases where there is actually a SHA1 conflict between all\n>>> possible tags that match a tag short-end then listing them and asking the\n>>> user to be more explicit is the right thing to do.  But that should be a\n>>> very rare case in practice, and designing for making this case easy is\n>>> the wrong approach.\n>>>\n>>> Instead, the common case of multiple remotes with duplicated tag names\n>>> referring to the same thing _and/or_ multiple remotes with distinct tags\n>>> names is what should be made easy to use with no extra steps.\n>>\n>> Again, I don't think that's the common case.  I think it's just as likely for\n>> there to be multiple remotes with duplicate tag names that refer to different\n>> objects.\n>\n> Why do you say so?  I'm curious to know what kind of work flow would do\n> that in practice.\n\nThe use case I have in mind is where a project makes use of other \nprojects, for example an application that uses some libraries.  The \napplication's repository could contain the full histories of the \nlibraries, each subtree-merged into a different directory.\n\nSo maybe that's not so common these days, but the current flat tag \nnamespace makes it pretty much impractical.\n\n\t\tM.\n"},{"id":"228492","messageId":"alpine.LFD.2.03.1309302323190.6331@syhkavp.arg","threadId":"34923","inReplyTo":"524A3BB6.9060808@xiplink.com","subject":"Re: Local tag killer","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2013-10-01T03:28:16Z","receivedAt":"2013-10-01T03:28:16Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 30 Sep 2013, Marc Branchaud wrote:\n\n> On 13-09-30 06:44 PM, Nicolas Pitre wrote:\n> > On Mon, 30 Sep 2013, Marc Branchaud wrote:\n> > \n> > > On 13-09-30 04:08 PM, Nicolas Pitre wrote:\n> > > > Again, in the cases where there is actually a SHA1 conflict between all\n> > > > possible tags that match a tag short-end then listing them and asking\n> > > > the\n> > > > user to be more explicit is the right thing to do.  But that should be a\n> > > > very rare case in practice, and designing for making this case easy is\n> > > > the wrong approach.\n> > > > \n> > > > Instead, the common case of multiple remotes with duplicated tag names\n> > > > referring to the same thing _and/or_ multiple remotes with distinct tags\n> > > > names is what should be made easy to use with no extra steps.\n> > > \n> > > Again, I don't think that's the common case.  I think it's just as likely\n> > > for\n> > > there to be multiple remotes with duplicate tag names that refer to\n> > > different\n> > > objects.\n> > \n> > Why do you say so?  I'm curious to know what kind of work flow would do\n> > that in practice.\n> \n> The use case I have in mind is where a project makes use of other projects,\n> for example an application that uses some libraries.  The application's\n> repository could contain the full histories of the libraries, each\n> subtree-merged into a different directory.\n> \n> So maybe that's not so common these days, but the current flat tag namespace\n> makes it pretty much impractical.\n\nBut with my proposal, you'd get a message saying that the tag \"baz\" is \nambigous, and that you'd have to use either \"libfoo/baz\" or \n\"libbar/baz\".\n\nThe current flat namespace makes many things virtually impractical \nindeed, even with the kernel workflow I described.\n\n\nNicolas\n"},{"id":"228510","messageId":"524AC405.3040209@xiplink.com","threadId":"34923","inReplyTo":"alpine.LFD.2.03.1309302323190.6331@syhkavp.arg","subject":"Re: Local tag killer","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2013-10-01T12:45:57Z","receivedAt":"2013-10-01T12:45:57Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 13-09-30 11:28 PM, Nicolas Pitre wrote:\n>\n> But with my proposal, you'd get a message saying that the tag \"baz\" is\n> ambigous, and that you'd have to use either \"libfoo/baz\" or\n> \"libbar/baz\".\n\nYes, and that's good.  I agree with your proposal.  Sorry if that wasn't \nclear.\n\n\t\tM.\n"}]}