{"thread":{"id":"26377","subject":"[1.8.0] Remote tag namespace","startedAt":"2011-02-01T10:44:50Z","lastAt":"2011-02-18T00:57:10Z","messageCount":104,"participants":["Nguyen Thai Ngoc Duy","Leo Razoumov","Marc Branchaud","Jeff King","Sverre Rabbelier","Johan Herland","Santi Béjar","Junio C Hamano","Kevin P. Fleming","Nicolas Pitre","Dmitry Potapov","Matthieu Moy","Bernhard R. Link","Enrico Weigelt","Jakub Narebski","Jay Soffian","Jonathan Nieder","Martin von Zweigbergk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"160162","messageId":"AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com","threadId":"26377","inReplyTo":null,"subject":"[1.8.0] Remote tag namespace","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T10:44:50Z","receivedAt":"2011-02-01T10:44:50Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 1, 2011 at 11:16 AM, Nicolas Pitre wrote:\n> On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote:\n>> Another random wish, which does not come with a proposal. How about\n>> tag namespace (ie. tags from a remote stay in remote namespace)?\n>\n> Please make this into a proper proposal.  this would be indeed a huge\n> improvement.\n\nOK I'm not familiar with tag code, but I can try.\n\nProposal:\n\nReserve refs/remote-tags namespace to store tags from remotes. Its\nstructure is the same as in refs/remotes. When pulling tags, put them\nin refs/remote-tags/ instead of refs/tags.\nTag dereference code will be taught about refs/remote-tags with\nsimilar deref order as in remote branches.\n\nConfig branch.*.globalTags (perhaps takes a pattern?) may be defined\nto create refs/tags/* in addition to refs/remote-tags//* when\nfetching tags.\n\nMigration plan:\n\nrefs/remote-tags will be used to store new tags unconditionally, which\nmeans there will be duplicates with the already-fetched tags in global\nnamespace. Perhaps we can check if they point to the same sha-1, then\nchoose not to annoy users with ambiguous tag messages?\n\nI suggest to add config compatibility.remoteTagNamespace, default to\nfalse, which retains current behavior (i.e. also create tags in global\nnamespace in addition to refs/remote-tags). After 1.8.0 (or a few more\ncycles) the default value becomes true. Users who wish to keep old\nbehavior can put \"false\" in their ~/.gitconfig.\n\nAfter a few years, remove support for the config key. Unrecognized\ncompatibility.* keys will abort program. Users are forced to new\nbehavior. I don't know, we may want to start annoy users that have the\nconfig key set a few cycles before we drop support.\n-- \nDuy\n"},{"id":"160167","messageId":"AANLkTimzvrJsGpc5T6D43RFQvqEu0WfSidbSw5ukahCy@mail.gmail.com","threadId":"26377","inReplyTo":"AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com","subject":"Re: [1.8.0] Remote tag namespace","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2011-02-01T14:10:20Z","receivedAt":"2011-02-01T14:10:20Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On Tue, Feb 1, 2011 at 05:44, Nguyen Thai Ngoc Duy wrote:\n> On Tue, Feb 1, 2011 at 11:16 AM, Nicolas Pitre wrote:\n>> On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote:\n>>> Another random wish, which does not come with a proposal. How about\n>>> tag namespace (ie. tags from a remote stay in remote namespace)?\n>>\n>> Please make this into a proper proposal.  this would be indeed a huge\n>> improvement.\n>\n> OK I'm not familiar with tag code, but I can try.\n>\n> Proposal:\n>\n\nRemote tag namespace is a great feature long overdue in git. Due to\ngit's current flat tag namespace I am forced to make my tags\nartificially long like\n\"my_project_repo_name/v-1.2.3\".\n\nLooking forward to remote tag namespace -- sooner the better!\n\n--Leo--\n"},{"id":"160177","messageId":"4D48219D.8060603@xiplink.com","threadId":"26377","inReplyTo":"AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com","subject":"Re: [1.8.0] Remote tag namespace","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-02-01T15:07:09Z","receivedAt":"2011-02-01T15:07:09Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-02-01 05:44 AM, Nguyen Thai Ngoc Duy wrote:\n> On Tue, Feb 1, 2011 at 11:16 AM, Nicolas Pitre wrote:\n>> On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote:\n>>> Another random wish, which does not come with a proposal. How about\n>>> tag namespace (ie. tags from a remote stay in remote namespace)?\n>>\n>> Please make this into a proper proposal. this would be indeed a huge\n>> improvement.\n> \n> OK I'm not familiar with tag code, but I can try.\n\nOK, that teaches me to read through _all_ the unread messages before posting!\n\nNeedless to say, I support this proposal.\n\n> Proposal:\n> \n> Reserve refs/remote-tags namespace to store tags from remotes. Its\n> structure is the same as in refs/remotes. When pulling tags, put them\n> in refs/remote-tags/ instead of refs/tags.\n> Tag dereference code will be taught about refs/remote-tags with\n> similar deref order as in remote branches.\n\nI suggested a different home for the tags, but I don't have any insight into\nwhat makes the most sense. I'll defer to wiser folk on this.\n\n> Config branch.*.globalTags (perhaps takes a pattern?) may be defined\n> to create refs/tags/* in addition to refs/remote-tags//* when\n> fetching tags.\n\nI may be getting into the weeds prematurely here, but why put the config item\nunder branch.* ? Or did you mean remote.*.globalTags? Personally, I don't\nsee a need for this. I'd rather have the rev-parse machinery search in\nremote tag namespaces if it can't find anything local.\n\n> Migration plan:\n> \n> refs/remote-tags will be used to store new tags unconditionally, which\n> means there will be duplicates with the already-fetched tags in global\n> namespace. Perhaps we can check if they point to the same sha-1, then\n> choose not to annoy users with ambiguous tag messages?\n\n(Again with the weeds...) I don't think we could do that. I'd want to be\nable to have my own (local) tags that refer to the same commits as one or\nmore remote tags, and I'd want to see them all.\n\nBetter for \"git tag\" to learn scoping options like \"git branch\": -a and -r.\n(Hmm, maybe git-tag's current -a could become -A...)\n\n> I suggest to add config compatibility.remoteTagNamespace, default to\n> false, which retains current behavior (i.e. also create tags in global\n> namespace in addition to refs/remote-tags). After 1.8.0 (or a few more\n> cycles) the default value becomes true. Users who wish to keep old\n> behavior can put \"false\" in their ~/.gitconfig.\n> \n> After a few years, remove support for the config key. Unrecognized\n> compatibility.* keys will abort program. Users are forced to new\n> behavior. I don't know, we may want to start annoy users that have the\n> config key set a few cycles before we drop support.\n\nSounds good. I'd vote for a faster transition, but that's just me. :)\n\n\t\tM.\n"},{"id":"160180","messageId":"AANLkTim4qOiF=3GMixZuWJs=cqcAtawtgkKzLiVdBhuZ@mail.gmail.com","threadId":"26377","inReplyTo":"4D48219D.8060603@xiplink.com","subject":"Re: [1.8.0] Remote tag namespace","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T15:35:46Z","receivedAt":"2011-02-01T15:35:46Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 1, 2011 at 10:07 PM, Marc Branchaud wrote:\n>> Config branch.*.globalTags (perhaps takes a pattern?) may be defined\n>> to create refs/tags/* in addition to refs/remote-tags//* when\n>> fetching tags.\n>\n> I may be getting into the weeds prematurely here, but why put the config item\n> under branch.* ?  Or did you mean remote.*.globalTags?  Personally, I don't\n> see a need for this.  I'd rather have the rev-parse machinery search in\n> remote tag namespaces if it can't find anything local.\n\nAhh.. yeah it's remote.*.globalTags. I don't know, some people might\nfind current behavior useful. So instead of dropping it entirely, I'd\nlimit it to certain remotes.\n\n>\n>> Migration plan:\n>>\n>> refs/remote-tags will be used to store new tags unconditionally, which\n>> means there will be duplicates with the already-fetched tags in global\n>> namespace. Perhaps we can check if they point to the same sha-1, then\n>> choose not to annoy users with ambiguous tag messages?\n>\n> (Again with the weeds...)  I don't think we could do that.  I'd want to be\n> able to have my own (local) tags that refer to the same commits as one or\n> more remote tags, and I'd want to see them all.\n\nFor listing tags (I forgot this) I think we just follow how git-branch\ndoes it: show only local tags unless -r (or some other option) is\ngiven. What I meant in the above paragraph is \"some-ref\" can refer to\nrefs/tags/some-ref or refs/remotes/foo/tags/some-ref, but I was wrong\non this. The latter can only be referred by foo/some-ref or with\nmigration support in your proposal.\n\n>\n> Better for \"git tag\" to learn scoping options like \"git branch\": -a and -r.\n> (Hmm, maybe git-tag's current -a could become -A...)\n\nWhen tags are put in remote namespace (wherever it actually is),\ngit-tag must learn -r like git-branch. I think option name change for\n-a is too late though. When \"git-ng\" rewrite project comes (that is\nafter libgit2 replaces git core), we may have everything consistent\nagain.\n\nPS. I bet git-ng would start after Wine 2.0 is released.\n-- \nDuy\n"},{"id":"160199","messageId":"20110201181428.GA6579@sigill.intra.peff.net","threadId":"26377","inReplyTo":"AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com","subject":"Re: [1.8.0] Remote tag namespace","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-01T18:14:29Z","receivedAt":"2011-02-01T18:14:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 01, 2011 at 05:44:50PM +0700, Nguyen Thai Ngoc Duy wrote:\n\n> OK I'm not familiar with tag code, but I can try.\n> \n> Proposal:\n> \n> Reserve refs/remote-tags namespace to store tags from remotes. Its\n> structure is the same as in refs/remotes. When pulling tags, put them\n> in refs/remote-tags/ instead of refs/tags.\n> Tag dereference code will be taught about refs/remote-tags with\n> similar deref order as in remote branches.\n\nThere are similar questions around remote notes refs. Should there also\nbe a refs/remote-notes? And there was some discussion recently about\nfetching remote replace refs.\n\nShould we perhaps be massaging refs/remotes into a structure to handle\nall of these things? Like:\n\n refs/remotes/origin/HEAD (-> refs/remotes/origin/heads/master)\n refs/remotes/origin/heads/master\n refs/remotes/origin/tags/v1.7.4\n refs/remotes/origin/notes/commit\n refs/remotes/origin/replace/f67e92af477a2255b64a1ece33d9d126e763fe9b\n\ni.e., make refs/remotes/* an actual mirror of selected parts of the\nremote's refs/ hierarchy. And then figure out sane rules for merging\nthose namespaces into the ref lookup procedure. For heads and tags,\nprobably some tweaking of the lookup rules in dwim_ref; for\nreplacements, probably you would want to manually say \"I am interested\nin this replace\" and copy or symref-link it into your refs/ hierarchy.\nAnd probably something similar with notes.\n\nObviously I haven't thought it all the way through, but it just seems a\nshame not to deal with other similar issues when looking at tags.\n\n-Peff\n"},{"id":"160237","messageId":"AANLkTimtU56BAnWU-2pY1npdkPdKEBq_CMCGwXUK+E=H@mail.gmail.com","threadId":"26377","inReplyTo":"20110201181428.GA6579@sigill.intra.peff.net","subject":"Re: [1.8.0] Remote tag namespace","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-01T23:14:26Z","receivedAt":"2011-02-01T23:14:26Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Tue, Feb 1, 2011 at 19:14, Jeff King wrote:\n> i.e., make refs/remotes/* an actual mirror of selected parts of the\n> remote's refs/ hierarchy. And then figure out sane rules for merging\n> those namespaces into the ref lookup procedure.\n\nJeff, Nguy, are either of you interested in writing up a new/modifying\nthis proposal to be about namespacing everything? I think it\ndefinitely makes sense to have a namespace for notes, replaces, as\nwell as tags, especially since it would also allow us to propagate\nthese by default (at least to the refs/remotes namespace), and think\nit's a good idea to go all the way if we're going to do this at all\n(or we'll have the same discussion again later for notes and replaces,\nand whatever comes after that).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"160238","messageId":"201102020015.27270.johan@herland.net","threadId":"26377","inReplyTo":"20110201181428.GA6579@sigill.intra.peff.net","subject":"Re: [1.8.0] Remote tag namespace","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-01T23:15:27Z","receivedAt":"2011-02-01T23:15:27Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 01 February 2011, Jeff King wrote:\n> On Tue, Feb 01, 2011 at 05:44:50PM +0700, Nguyen Thai Ngoc Duy wrote:\n> > OK I'm not familiar with tag code, but I can try.\n> > \n> > Proposal:\n> > \n> > Reserve refs/remote-tags namespace to store tags from remotes. Its\n> > structure is the same as in refs/remotes. When pulling tags, put them\n> > in refs/remote-tags/ instead of refs/tags.\n> > Tag dereference code will be taught about refs/remote-tags with\n> > similar deref order as in remote branches.\n> \n> There are similar questions around remote notes refs. Should there also\n> be a refs/remote-notes? And there was some discussion recently about\n> fetching remote replace refs.\n> \n> Should we perhaps be massaging refs/remotes into a structure to handle\n> all of these things? Like:\n> \n> refs/remotes/origin/HEAD (-> refs/remotes/origin/heads/master)\n> refs/remotes/origin/heads/master\n> refs/remotes/origin/tags/v1.7.4\n> refs/remotes/origin/notes/commit\n> refs/remotes/origin/replace/f67e92af477a2255b64a1ece33d9d126e763fe9b\n> \n> i.e., make refs/remotes/* an actual mirror of selected parts of the\n> remote's refs/ hierarchy. And then figure out sane rules for merging\n> those namespaces into the ref lookup procedure. For heads and tags,\n> probably some tweaking of the lookup rules in dwim_ref; for\n> replacements, probably you would want to manually say \"I am interested\n> in this replace\" and copy or symref-link it into your refs/ hierarchy.\n\nI fully agree.\n\nIn addition - as discussed in http://thread.gmane.org/gmane.comp.version-\ncontrol.git/160503/focus=160795 - we should also tweak the refspec format to \nmake tag auto-following explicit in the refspec.\n\n> And probably something similar with notes.\n\n(going slightly offtopic with the notes discussion here)\n\nI've been thinking that notes should be organized much in the same fashion \nas branches/heads. There should be remote notes refs that should only be \nupdated from the remote, and there should be local notes refs in \nrefs/notes/*. You should be able to configure upstream relationships between \nlocal notes refs and remote notes refs (e.g. notes.foo.remote and \nnotes.foo.merge), and auto-merge them on \"git notes pull\".\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160246","messageId":"201102020322.00171.johan@herland.net","threadId":"26377","inReplyTo":"AANLkTimtU56BAnWU-2pY1npdkPdKEBq_CMCGwXUK+E=H@mail.gmail.com","subject":"[1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-02T02:21:59Z","receivedAt":"2011-02-02T02:21:59Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 02 February 2011, Sverre Rabbelier wrote:\n> On Tue, Feb 1, 2011 at 19:14, Jeff King wrote:\n> > i.e., make refs/remotes/* an actual mirror of selected parts of the\n> > remote's refs/ hierarchy. And then figure out sane rules for merging\n> > those namespaces into the ref lookup procedure.\n> \n> Jeff, Nguy, are either of you interested in writing up a new/modifying\n> this proposal to be about namespacing everything?\n\nHere's my go at phrasing this in a proposal format. Feel free to revise and \nresend:\n\n\nProposal:\n\nCurrently, git stores remote refs in the local repo by default as follows:\n\n Remote repo -> Local repo\n ---------------------------------------------------------\n HEAD refs/remotes/$remote/HEAD (implicit)\n refs/heads/* refs/remotes/$remote/*\n refs/tags/* refs/tags/* (implicit, autofollow)\n refs/replace/* (TBD)\n refs/notes/* (TBD)\n\nSeveral users report that they are confused by the difference in how heads \nand tags are mapped, and by the implicit mappings that are not mentioned in \nthe configured refspecs. Also, as users want to share ever more different \ntypes of refs (replace refs and notes refs have been discussed recently), \nthe existing ref mappings (aka. refspecs) do not suggest a natural/intuitive \nmapping for the new ref types.\n\nInstead, we should change the default ref mappings into the following:\n\n Remote repo -> Local repo\n --------------------------------------------------\n HEAD refs/remotes/$remote/HEAD\n refs/heads/* refs/remotes/$remote/heads/*\n refs/tags/* refs/remotes/$remote/tags/*\n refs/replace/* refs/remotes/$remote/replace/*\n refs/notes/* refs/remotes/$remote/notes/*\n\nIn short, we make refs/remotes/$remote/* an actual mirror of selected parts \nof the remote's refs/* hierarchy. This provides consistent namespaces for \nremote refs that naturally allows adding new ref types in the future.\n\nThis change obviously affects our ref-handling code:\n\n- Remote tags are now stored separate from local tags. When looking up a \nshorthand tag name (e.g. v1.7.4), we should consult local tags \n(refs/tags/v1.7.4) before remote tags (refs/remotes/*/tags/v1.7.4 [1]). See \n[2] for more details.\n\n- Remote heads have moved into refs/remotes/$remote/heads/*, hence \ninvalidating shorthand remote head names, like \"origin/master\". We should \nchange the lookup code, so that a shorthand ref of the form \"$remote/$head\" \nwhere \"$remote\" happens to match a configured remote is eventually expanded \ninto lookup for \"refs/remotes/$remote/heads/$head\" [3].\n\n- We might want to generalize the handling of \"$remote/$head\" into allowing \nshorthands like \"$remote/$tag\", \"$remote/$replace\" and \"$remote/$note\" as \nwell (provided, of course, that they match unambiguously).\n\n- All fetch refspecs should be given explicitly.\n\nSub-proposal: While we are changing the default refspecs, we should also \nconsider whether we want to keep the auto-following behavior that Git \ncurrently does for tags (don't fetch tags that refer to objects not \notherwise fetched by another refspec). If we simply make an explicit \n\"+refs/tags/*:refs/remotes/$remote/tags/*\" refspec, we will lose the auto-\nfollowing behavior. If we do want to keep the auto-following behavior, we \ncould for example add a \"~\" prefix to the refspec to trigger auto-following \nbehavior (i.e. this refspec only applies to refs that happen to point at \nobjects fetched by way of a different refspec). See \nhttp://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160795 \nfor more details.\n\n\nRisks:\n\nExisting scripts/programs may make assumptions about the layout of remote \nrefs without consulting the configured refspecs. However, such \nscripts/programs may also break today when non-default refspecs are used.\n\nWhen remotes have conflicting tags (same tag name points to different \nobjects), and the tag name does not exist locally (in refs/tags/*), looking \nup the shorthand tag name will result in an \"ambiguous ref\" error (instead \nof silently adopting whichever tag was fetched first). Although many \nconsider this an improvement on the current behavior, there may be scenarios \nwhere this causes problems in external scripts/programs.\n\nExisting scripts/programs that assume and depend on the current implicit \nrefspecs (or the tag auto-following behavior), might encounter problems when \nwe drop these in favor of explicit refspecs.\n\n\nMigration plan:\n\nThe main part of this proposal is simply changing the default refspecs. As \nsuch, the proposal can be simulated in current Git versions by setting up \ncustom refspecs according to the above table of ref mappings.\n\nIn v1.8.0, we should default to the new default refspecs when creating new \nremotes. However, existing remotes (created pre-v1.8.0) must continue to \nwork as before, so we cannot simply remove the implicit refspecs (or tag \nauto-following). Instead we need to make sure that the implicit refspecs is \nNOT applied to the new-style remotes. Identifying new-style vs. old-style \nremotes can be done by looking at the refspec itself (old-style: \n\"refs/remotes/$remote/*\", new-style: \"refs/remotes/$remote/heads/*\"), or \n(worst case) by introducing a config variable specifying the desired \nbehavior (defaulting to old-style).\n\nWhen adding the new rules for looking up shorthand refs (described above), \nwe should carefully verify that these won't cause regressions when applied \nto old-style refspecs in existing repos.\n\nIn a later major version we can consider removing the (by then ancient) \nimplicit refspecs, and any other outdated compatibility measures code in our \nref lookup code.\n\n\nHave fun! :)\n\n...Johan\n\n\n[1]: The \"refs/remotes/*/tags/v1.7.4\" is not hardcoded, but rather the \n(default) result of mapping \"refs/tags/v1.7.4\" through each remote's \nrefspecs as defined in the config.\n\n[2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local tag \n(refs/tags/v1.7.4) is found, then we have an unambiguous match. If no local \ntag is found, we look up the tag name in all configured remotes (using the \nmethod described in [1]). If the tag name exists in one or more remotes, and \nthose remotes all agree on its ultimate object name (after applying e.g. \n^{commit} or whatever is appropriate in the context of the lookup), then we \nalso have an unambiguous match. However, if the tag name exists in multiple \nremotes, and they do NOT all agree on its ultimate object name, then the \nshorthand tag name is ambiguous and the lookup fails. The user can always \nresolve this ambiguity by creating a local tag (refs/tags/v1.7.4) pointing \nto the desired object.\n\n[3]: As in [1], the \"refs/remotes/$remote/heads/$head\" is not hardcoded, but \nrather the result of mapping \"refs/heads/$head\" through the refspecs for \n$remote as defined in the config.\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160271","messageId":"AANLkTimqQtLB--7pwwTALmcchnNCX0nm4Rfx8w1gp74T@mail.gmail.com","threadId":"26377","inReplyTo":"201102020322.00171.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2011-02-02T13:27:30Z","receivedAt":"2011-02-02T13:27:30Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Wed, Feb 2, 2011 at 3:21 AM, Johan Herland wrote:\n> On Wednesday 02 February 2011, Sverre Rabbelier wrote:\n>> On Tue, Feb 1, 2011 at 19:14, Jeff King wrote:\n>> > i.e., make refs/remotes/* an actual mirror of selected parts of the\n>> > remote's refs/ hierarchy. And then figure out sane rules for merging\n>> > those namespaces into the ref lookup procedure.\n>>\n>> Jeff, Nguy, are either of you interested in writing up a new/modifying\n>> this proposal to be about namespacing everything?\n>\n> Here's my go at phrasing this in a proposal format. Feel free to revise and\n> resend:\n>\n\n+1\n>\n> Proposal:\n>\n> Currently, git stores remote refs in the local repo by default as follows:\n>\n>  Remote repo    ->   Local repo\n>  ---------------------------------------------------------\n>  HEAD                refs/remotes/$remote/HEAD  (implicit)\n>  refs/heads/*        refs/remotes/$remote/*\n>  refs/tags/*         refs/tags/*                (implicit, autofollow)\n>  refs/replace/*      (TBD)\n>  refs/notes/*        (TBD)\n>\n> Several users report that they are confused by the difference in how heads\n> and tags are mapped, and by the implicit mappings that are not mentioned in\n> the configured refspecs. Also, as users want to share ever more different\n> types of refs (replace refs and notes refs have been discussed recently),\n> the existing ref mappings (aka. refspecs) do not suggest a natural/intuitive\n> mapping for the new ref types.\n>\n> Instead, we should change the default ref mappings into the following:\n>\n>  Remote repo    ->   Local repo\n>  --------------------------------------------------\n>  HEAD                refs/remotes/$remote/HEAD\n>  refs/heads/*        refs/remotes/$remote/heads/*\n>  refs/tags/*         refs/remotes/$remote/tags/*\n>  refs/replace/*      refs/remotes/$remote/replace/*\n>  refs/notes/*        refs/remotes/$remote/notes/*\n\n[...]\n\n> - We might want to generalize the handling of \"$remote/$head\" into allowing\n> shorthands like \"$remote/$tag\", \"$remote/$replace\" and \"$remote/$note\" as\n> well (provided, of course, that they match unambiguously).\n\n[...]\n\n> [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local tag\n> (refs/tags/v1.7.4) is found, then we have an unambiguous match. If no local\n> tag is found, we look up the tag name in all configured remotes (using the\n> method described in [1]). If the tag name exists in one or more remotes, and\n> those remotes all agree on its ultimate object name (after applying e.g.\n> ^{commit} or whatever is appropriate in the context of the lookup), then we\n> also have an unambiguous match. However, if the tag name exists in multiple\n> remotes, and they do NOT all agree on its ultimate object name, then the\n> shorthand tag name is ambiguous and the lookup fails. The user can always\n> resolve this ambiguity by creating a local tag (refs/tags/v1.7.4) pointing\n> to the desired object.\n\nAnd the other way around. What would be the output of \"git name-rev\" ,\n\"git describe\", \"--decorate\", and such? $remote/tags/$tag?\n$remote/$tag? $tag?\n\nI would say $remote/$tag for \"git name-rev\" and \"--decorate\" but $tag\nfor \"git describe\" as it is usually used to create files, i.e.\ngit-1.7.4.261.g705f.tar.gz. And I think many people, me included, do\nnot expect to have an / in the \"git describe\" output, at least in the\ndefault output (in contrast with the --all flag).\n\nAnother point to consider is if we want a default remote for tags, a\nconfig tags.defaultRemote (TBD), defaulting to origin, specifying the\ndefault remote for tags. There would be a hierarchy: local tags,\ndefault remote tags, remote tags. With this if one tag is on multiple\nremote the tag from the default remote always wins.\n\nIn this way all the tag related input/output would no change much. For\nexample all the decoration would be $tag instead of origin/tag.\n\nHTH,\nSanti\n"},{"id":"160274","messageId":"201102021651.21669.johan@herland.net","threadId":"26377","inReplyTo":"AANLkTimqQtLB--7pwwTALmcchnNCX0nm4Rfx8w1gp74T@mail.gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-02T15:51:21Z","receivedAt":"2011-02-02T15:51:21Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 02 February 2011, Santi Béjar wrote:\n> On Wednesday 02 February 2011, Johan Herland wrote:\n> > Proposal:\n> >\n> > Currently, git stores remote refs in the local repo by default as\n> > follows:\n> >\n> >  Remote repo    ->   Local repo\n> >  ---------------------------------------------------------\n> >  HEAD                refs/remotes/$remote/HEAD  (implicit)\n> >  refs/heads/*        refs/remotes/$remote/*\n> >  refs/tags/*         refs/tags/*     (implicit, autofollow)\n> >  refs/replace/*      (TBD) \n> >  refs/notes/*        (TBD)\n> >\n> > Instead, we should change the default ref mappings into the\n> > following:\n> >\n> >  Remote repo    ->   Local repo\n> >  --------------------------------------------------\n> >  HEAD                refs/remotes/$remote/HEAD\n> >  refs/heads/*        refs/remotes/$remote/heads/*\n> >  refs/tags/*         refs/remotes/$remote/tags/*\n> >  refs/replace/*      refs/remotes/$remote/replace/*\n> >  refs/notes/*        refs/remotes/$remote/notes/*\n>\n> [...]\n>\n> > - We might want to generalize the handling of \"$remote/$head\" into\n> > allowing shorthands like \"$remote/$tag\", \"$remote/$replace\" and\n> > \"$remote/$note\" as well (provided, of course, that they match\n> > unambiguously).\n>\n> [...]\n>\n> > [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local\n> > tag (refs/tags/v1.7.4) is found, then we have an unambiguous match.\n> > If no local tag is found, we look up the tag name in all configured\n> > remotes (using the method described in [1]). If the tag name exists\n> > in one or more remotes, and those remotes all agree on its ultimate\n> > object name (after applying e.g. ^{commit} or whatever is\n> > appropriate in the context of the lookup), then we also have an\n> > unambiguous match. However, if the tag name exists in multiple\n> > remotes, and they do NOT all agree on its ultimate object name,\n> > then the shorthand tag name is ambiguous and the lookup fails. The\n> > user can always resolve this ambiguity by creating a local tag\n> > (refs/tags/v1.7.4) pointing to the desired object.\n>\n> And the other way around. What would be the output of \"git name-rev\"\n> , \"git describe\", \"--decorate\", and such? $remote/tags/$tag?\n> $remote/$tag? $tag?\n>\n> I would say $remote/$tag for \"git name-rev\" and \"--decorate\" but $tag\n> for \"git describe\" as it is usually used to create files, i.e.\n> git-1.7.4.261.g705f.tar.gz. And I think many people, me included, do\n> not expect to have an / in the \"git describe\" output, at least in the\n> default output (in contrast with the --all flag).\n\nThanks for raising an important point.\n\nI don't buy the file name creation argument, as 'describe' is used from \nmany different contexts, and file name creation is nowhere documented \nas one of its primary objectives.\n\nStill, the objective of 'describe' is to create a human-readable string \nthat tries to say something meaningful about a commit in relation to \nits preceding history, while at the same time uniquely identifying the \ncommit. The \"uniquely identifying\" part is taken care of by \nthe \"-g\" part of the output, while the initial \"-\" \npart makes it human-friendly. Therefore, we only care that the \n is fairly unambiguous in the mind of the reader. From this \nperspective, which of the alternatives makes more sense? I would \ndisqualify \"$remote/$tag\" and \"$remote/tags/$tag\", since the $remote \nname is repo-specific, and 'describe' output is often passed around \nbetween multiple developers/repos. Hence, I think that \"$tag\" is a good \nchoice for 'describe'. If \"$tag\" is ambiguous in the current repo, then \nan \"ambiguous tag\" tag warning can be printed, but I would still \nuse \"$tag\".\n\nWhen it comes to 'name-rev' and '--decorate', those are (AFAICS) much \nmore repo-specific, and seldom passed between users. Also, they don't \nhave the \"-g\" part from the 'describe' output. Hence, in this \ncase, I consider unique identification (unambiguity) much more \nimportant than not displaying $remote names. Therefore, I'd propose \nusing the shortest unambiguous alternative.\n\n> Another point to consider is if we want a default remote for tags, a\n> config tags.defaultRemote (TBD), defaulting to origin, specifying the\n> default remote for tags. There would be a hierarchy: local tags,\n> default remote tags, remote tags. With this if one tag is on multiple\n> remote the tag from the default remote always wins.\n>\n> In this way all the tag related input/output would no change much.\n> For example all the decoration would be $tag instead of origin/tag.\n\nAgreed, tags.defaultRemote (or tags.preferredRemote if I'm allowed to \nbikeshed) may be a valuable addition. Another way to achieve this would \nbe to explicitly copy tags from the preferred remote (e.g. origin) \ndirectly into refs/tags. I.e. in addition to the (new) default tag \nrefspec\n\n\t+refs/tags/*:refs/remotes/origin/tags/*\n\nyou could add an _additional_ refspec\n\n\trefs/tags/*:refs/tags/*\n\nthat would also copy all of origin's tags directly into your local tag \nnamespace.\n\n\nThanks for the feedback! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160275","messageId":"AANLkTimoj2o0h-YEAaMi_LWK9gDTg8uzg6w2eLyMg_Ki@mail.gmail.com","threadId":"26377","inReplyTo":"201102021651.21669.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2011-02-02T16:19:49Z","receivedAt":"2011-02-02T16:19:49Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Wed, Feb 2, 2011 at 4:51 PM, Johan Herland wrote:\n> On Wednesday 02 February 2011, Santi Béjar wrote:\n>> On Wednesday 02 February 2011, Johan Herland wrote:\n>> > Proposal:\n>> >\n>> > Currently, git stores remote refs in the local repo by default as\n>> > follows:\n>> >\n>> >  Remote repo    ->   Local repo\n>> >  ---------------------------------------------------------\n>> >  HEAD                refs/remotes/$remote/HEAD  (implicit)\n>> >  refs/heads/*        refs/remotes/$remote/*\n>> >  refs/tags/*         refs/tags/*         (implicit, autofollow)\n>> >  refs/replace/*      (TBD)\n>> >  refs/notes/*        (TBD)\n>> >\n>> > Instead, we should change the default ref mappings into the\n>> > following:\n>> >\n>> >  Remote repo    ->   Local repo\n>> >  --------------------------------------------------\n>> >  HEAD                refs/remotes/$remote/HEAD\n>> >  refs/heads/*        refs/remotes/$remote/heads/*\n>> >  refs/tags/*         refs/remotes/$remote/tags/*\n>> >  refs/replace/*      refs/remotes/$remote/replace/*\n>> >  refs/notes/*        refs/remotes/$remote/notes/*\n>>\n>> [...]\n>>\n>> > - We might want to generalize the handling of \"$remote/$head\" into\n>> > allowing shorthands like \"$remote/$tag\", \"$remote/$replace\" and\n>> > \"$remote/$note\" as well (provided, of course, that they match\n>> > unambiguously).\n>>\n>> [...]\n>>\n>> > [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local\n>> > tag (refs/tags/v1.7.4) is found, then we have an unambiguous match.\n>> > If no local tag is found, we look up the tag name in all configured\n>> > remotes (using the method described in [1]). If the tag name exists\n>> > in one or more remotes, and those remotes all agree on its ultimate\n>> > object name (after applying e.g. ^{commit} or whatever is\n>> > appropriate in the context of the lookup), then we also have an\n>> > unambiguous match. However, if the tag name exists in multiple\n>> > remotes, and they do NOT all agree on its ultimate object name,\n>> > then the shorthand tag name is ambiguous and the lookup fails. The\n>> > user can always resolve this ambiguity by creating a local tag\n>> > (refs/tags/v1.7.4) pointing to the desired object.\n>>\n>> And the other way around. What would be the output of \"git name-rev\"\n>> , \"git describe\", \"--decorate\", and such? $remote/tags/$tag?\n>> $remote/$tag? $tag?\n>>\n>> I would say $remote/$tag for \"git name-rev\" and \"--decorate\" but $tag\n>> for \"git describe\" as it is usually used to create files, i.e.\n>> git-1.7.4.261.g705f.tar.gz. And I think many people, me included, do\n>> not expect to have an / in the \"git describe\" output, at least in the\n>> default output (in contrast with the --all flag).\n>\n> Thanks for raising an important point.\n>\n> I don't buy the file name creation argument, as 'describe' is used from\n> many different contexts, and file name creation is nowhere documented\n> as one of its primary objectives.\n\nYes, I know it is used from many different contexts, but one important\none is the creation of the tar files, even git.git's Makefile assumes\nthis. But as at the end we agree...\n\n>\n> Still, the objective of 'describe' is to create a human-readable string\n> that tries to say something meaningful about a commit in relation to\n> its preceding history, while at the same time uniquely identifying the\n> commit. The \"uniquely identifying\" part is taken care of by\n> the \"-g\" part of the output, while the initial \"-\"\n> part makes it human-friendly. Therefore, we only care that the\n> is fairly unambiguous in the mind of the reader. From this\n> perspective, which of the alternatives makes more sense? I would\n> disqualify \"$remote/$tag\" and \"$remote/tags/$tag\", since the $remote\n> name is repo-specific, and 'describe' output is often passed around\n> between multiple developers/repos. Hence, I think that \"$tag\" is a good\n> choice for 'describe'. If \"$tag\" is ambiguous in the current repo, then\n> an \"ambiguous tag\" tag warning can be printed, but I would still\n> use \"$tag\".\n>\n> When it comes to 'name-rev' and '--decorate', those are (AFAICS) much\n> more repo-specific, and seldom passed between users. Also, they don't\n> have the \"-g\" part from the 'describe' output. Hence, in this\n> case, I consider unique identification (unambiguity) much more\n> important than not displaying $remote names. Therefore, I'd propose\n> using the shortest unambiguous alternative.\n\nI agree. Something like this I had in mind :)\n\n\n>\n>> Another point to consider is if we want a default remote for tags, a\n>> config tags.defaultRemote (TBD), defaulting to origin, specifying the\n>> default remote for tags. There would be a hierarchy: local tags,\n>> default remote tags, remote tags. With this if one tag is on multiple\n>> remote the tag from the default remote always wins.\n>>\n>> In this way all the tag related input/output would no change much.\n>> For example all the decoration would be $tag instead of origin/tag.\n>\n> Agreed, tags.defaultRemote (or tags.preferredRemote if I'm allowed to\n> bikeshed) may be a valuable addition. Another way to achieve this would\n> be to explicitly copy tags from the preferred remote (e.g. origin)\n> directly into refs/tags. I.e. in addition to the (new) default tag\n> refspec\n>\n>        +refs/tags/*:refs/remotes/origin/tags/*\n>\n> you could add an _additional_ refspec\n>\n>        refs/tags/*:refs/tags/*\n>\n> that would also copy all of origin's tags directly into your local tag\n> namespace.\n\nYes, you always can add this refspec but I don't want to pollute my\n\"strict\" local tags. And moreover with the config tags.preferredRemote\nyou can change from one preferred remote to another just changing a\nconfig.\n\n> Thanks for the feedback! :)\n\nThanks for the proposal!\n\nHTH,\nSanti\n"},{"id":"160286","messageId":"4D49B2BA.5050002@xiplink.com","threadId":"26377","inReplyTo":"AANLkTim4qOiF=3GMixZuWJs=cqcAtawtgkKzLiVdBhuZ@mail.gmail.com","subject":"Re: [1.8.0] Remote tag namespace","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-02-02T19:38:34Z","receivedAt":"2011-02-02T19:38:34Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-02-01 10:35 AM, Nguyen Thai Ngoc Duy wrote:\n> On Tue, Feb 1, 2011 at 10:07 PM, Marc Branchaud wrote:\n>>> Config branch.*.globalTags (perhaps takes a pattern?) may be defined\n>>> to create refs/tags/* in addition to refs/remote-tags//* when\n>>> fetching tags.\n>>\n>> I may be getting into the weeds prematurely here, but why put the config item\n>> under branch.* ? Or did you mean remote.*.globalTags? Personally, I don't\n>> see a need for this. I'd rather have the rev-parse machinery search in\n>> remote tag namespaces if it can't find anything local.\n>\n> Ahh.. yeah it's remote.*.globalTags. I don't know, some people might\n> find current behavior useful. So instead of dropping it entirely, I'd\n> limit it to certain remotes.\n\nIMHO, it's best not to assume what people might want. Better to wait \nfor someone to ask for something specific.\n\n[ ...snip... ]\n\n> When tags are put in remote namespace (wherever it actually is),\n> git-tag must learn -r like git-branch. I think option name change for\n> -a is too late though. When \"git-ng\" rewrite project comes (that is\n> after libgit2 replaces git core), we may have everything consistent\n> again.\n\nI think we could start by making \"git tag -A\" a synonym for \"git tag -a\" \nwith a verbose warning when \"-a\" is used that it'll soon gain a \ndifferent meaning.\n\nAlso, during the transition \"git tag -a\" without any other options could \n(without the big warning) list all local and remote tags (like \"git \nbranch -a\") and if someone wanted to make an annotated tag of the \ncurrent tip they could do \"git tag -A\" or \"git tag -a HEAD\".\n\n\t\tM.\n"},{"id":"160313","messageId":"AANLkTi=tMq18mKqr0cp9rXqtDApKu3P_AZGyX6fA3hsx@mail.gmail.com","threadId":"26377","inReplyTo":"201102020322.00171.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-03T05:33:48Z","receivedAt":"2011-02-03T05:33:48Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland wrote:\n> Migration plan:\n> ...\n> In v1.8.0, we should default to the new default refspecs when creating new\n> remotes. However, existing remotes (created pre-v1.8.0) must continue to\n> work as before, so we cannot simply remove the implicit refspecs (or tag\n> auto-following). Instead we need to make sure that the implicit refspecs is\n> NOT applied to the new-style remotes. Identifying new-style vs. old-style\n> remotes can be done by looking at the refspec itself (old-style:\n> \"refs/remotes/$remote/*\", new-style: \"refs/remotes/$remote/heads/*\"), or\n> (worst case) by introducing a config variable specifying the desired\n> behavior (defaulting to old-style).\n\nHow about convert old style remotes to new style? Should it be done\nautomatically when new git detects old style remotes, or done by\ncommand, or manually?\n-- \nDuy\n"},{"id":"160320","messageId":"201102030946.01086.johan@herland.net","threadId":"26377","inReplyTo":"AANLkTi=tMq18mKqr0cp9rXqtDApKu3P_AZGyX6fA3hsx@mail.gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-03T08:46:00Z","receivedAt":"2011-02-03T08:46:00Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:\n> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland wrote:\n> > Migration plan:\n> > ...\n> > In v1.8.0, we should default to the new default refspecs when creating\n> > new remotes. However, existing remotes (created pre-v1.8.0) must\n> > continue to work as before, so we cannot simply remove the implicit\n> > refspecs (or tag auto-following). Instead we need to make sure that\n> > the implicit refspecs is NOT applied to the new-style remotes.\n> > Identifying new-style vs. old-style remotes can be done by looking at\n> > the refspec itself (old-style: \"refs/remotes/$remote/*\", new-style:\n> > \"refs/remotes/$remote/heads/*\"), or (worst case) by introducing a\n> > config variable specifying the desired behavior (defaulting to\n> > old-style).\n> \n> How about convert old style remotes to new style? Should it be done\n> automatically when new git detects old style remotes, or done by\n> command, or manually?\n\nI don't think we want to mess with existing remote refs without the user's \nconsent, especially since the user might have all kinds of repo-specific \npractices tied to the old layout of remote refs.\n\nProviding a command to do it (git remote renew?) is a much better way to go \nabout it, IMHO. Still, it is vitally important that new git keeps working \nwith old-style remotes.\n\nAnother issue is whether we should automatically make the old-style implicit \nrefspecs into _explicit_ (but still old-style) refspecs. I.e. when \nencountering an old-style remote, new git could automatically add the \nfollowing refspecs to the remote:\n\n\t+HEAD:refs/remotes/origin/HEAD\n ~refs/tags/*:refs/tags/*\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160323","messageId":"AANLkTinrqCaD_vg7Ah4Tjgoa-njEBEmiYt15ojtsazKw@mail.gmail.com","threadId":"26377","inReplyTo":"201102020322.00171.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-03T11:35:20Z","receivedAt":"2011-02-03T11:35:20Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland wrote:\n> Migration plan:\n> ...\n> In v1.8.0, we should default to the new default refspecs when creating new\n> remotes. However, existing remotes (created pre-v1.8.0) must continue to\n> work as before, so we cannot simply remove the implicit refspecs (or tag\n> auto-following). Instead we need to make sure that the implicit refspecs is\n> NOT applied to the new-style remotes. Identifying new-style vs. old-style\n> remotes can be done by looking at the refspec itself (old-style:\n> \"refs/remotes/$remote/*\", new-style: \"refs/remotes/$remote/heads/*\"), or\n> (worst case) by introducing a config variable specifying the desired\n> behavior (defaulting to old-style).\n\nI'd prefer config var (remote.*.implicitRules, maybe). We don't\nreserve heads, tags... in remote namespace for ourselves. Some users\nmight have already have branches heads/ant, heads/bee... making new\nstyle detection unreliable.\n\nSo I propose add remote.*.implicitRules = false since 1.8.0 for new\nremotes as a way to detect new/old style. The default value would be\ntrue.\n\nBut I don't want to keep adding remote.*.implicitRules on new remotes\nforever. I suppose one year after 1.8.0, the new behavior is\nwidespread enough. We can then annoy users to add\nremote.*.implicitRules for all old remotes. There should be no more\ndefault value after 1-2 years. We then flip the default value and\nwon't automatically add remote.*.implicitRules = false on new remotes.\n-- \nDuy\n"},{"id":"160325","messageId":"201102031410.58623.johan@herland.net","threadId":"26377","inReplyTo":"AANLkTinrqCaD_vg7Ah4Tjgoa-njEBEmiYt15ojtsazKw@mail.gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-03T13:10:58Z","receivedAt":"2011-02-03T13:10:58Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:\n> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland \nwrote:\n> > Migration plan:\n> > ...\n> > In v1.8.0, we should default to the new default refspecs when\n> > creating new remotes. However, existing remotes (created\n> > pre-v1.8.0) must continue to work as before, so we cannot simply\n> > remove the implicit refspecs (or tag auto-following). Instead we\n> > need to make sure that the implicit refspecs is NOT applied to the\n> > new-style remotes. Identifying new-style vs. old-style remotes can\n> > be done by looking at the refspec itself (old-style:\n> > \"refs/remotes/$remote/*\", new-style:\n> > \"refs/remotes/$remote/heads/*\"), or (worst case) by introducing a\n> > config variable specifying the desired behavior (defaulting to\n> > old-style).\n>\n> I'd prefer config var (remote.*.implicitRules, maybe). We don't\n> reserve heads, tags... in remote namespace for ourselves. Some users\n> might have already have branches heads/ant, heads/bee... making new\n> style detection unreliable.\n>\n> So I propose add remote.*.implicitRules = false since 1.8.0 for new\n> remotes as a way to detect new/old style. The default value would be\n> true.\n>\n> But I don't want to keep adding remote.*.implicitRules on new remotes\n> forever. I suppose one year after 1.8.0, the new behavior is\n> widespread enough. We can then annoy users to add\n> remote.*.implicitRules for all old remotes. There should be no more\n> default value after 1-2 years. We then flip the default value and\n> won't automatically add remote.*.implicitRules = false on new\n> remotes.\n\nI don't have a problem with this, other than bikeshedding over the \nvariable name: I find remote.*.implicitFetchRefspecs more descriptive.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160327","messageId":"AANLkTindnAFix+u3HKW0V-ArkzjyrDhpmN6gf9PSj0_G@mail.gmail.com","threadId":"26377","inReplyTo":"201102031410.58623.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2011-02-03T14:10:19Z","receivedAt":"2011-02-03T14:10:19Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"> On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:\n>> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland \n> wrote:\n>> > Migration plan:\n>> > ...\n>> > In v1.8.0, we should default to the new default refspecs when\n>> > creating new remotes. However, existing remotes (created\n>> > pre-v1.8.0) must continue to work as before, so we cannot simply\n>> > remove the implicit refspecs (or tag auto-following). Instead we\n>> > need to make sure that the implicit refspecs is NOT applied to the\n>> > new-style remotes. Identifying new-style vs. old-style remotes can\n>> > be done by looking at the refspec itself (old-style:\n>> > \"refs/remotes/$remote/*\", new-style:\n>> > \"refs/remotes/$remote/heads/*\"), or (worst case) by introducing a\n>> > config variable specifying the desired behavior (defaulting to\n>> > old-style).\n>>\n>> I'd prefer config var (remote.*.implicitRules, maybe). We don't\n>> reserve heads, tags... in remote namespace for ourselves. Some users\n>> might have already have branches heads/ant, heads/bee... making new\n>> style detection unreliable.\n\nI don't quite follow the argument. For me the question is how likely\nan old-time user has modified the refspec to read\n\"refs/remotes/$remote/heads/* (new-style). I think this is very, very\nunlikely and thus the \"heuristic\" to detect old/new style works most\nof the time and there is no need for a new config/compatibility key.\n\nHTH,\nSanti\n"},{"id":"160334","messageId":"AANLkTikywtYzQorKPQoGNjWgyC9=iZAqNe-YfFsaczu_@mail.gmail.com","threadId":"26377","inReplyTo":"AANLkTindnAFix+u3HKW0V-ArkzjyrDhpmN6gf9PSj0_G@mail.gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-03T15:48:15Z","receivedAt":"2011-02-03T15:48:15Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Feb 3, 2011 at 9:10 PM, Santi Béjar wrote:\n>> On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:\n>>> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland \n>> wrote:\n>>> > Migration plan:\n>>> > ...\n>>> > In v1.8.0, we should default to the new default refspecs when\n>>> > creating new remotes. However, existing remotes (created\n>>> > pre-v1.8.0) must continue to work as before, so we cannot simply\n>>> > remove the implicit refspecs (or tag auto-following). Instead we\n>>> > need to make sure that the implicit refspecs is NOT applied to the\n>>> > new-style remotes. Identifying new-style vs. old-style remotes can\n>>> > be done by looking at the refspec itself (old-style:\n>>> > \"refs/remotes/$remote/*\", new-style:\n>>> > \"refs/remotes/$remote/heads/*\"), or (worst case) by introducing a\n>>> > config variable specifying the desired behavior (defaulting to\n>>> > old-style).\n>>>\n>>> I'd prefer config var (remote.*.implicitRules, maybe). We don't\n>>> reserve heads, tags... in remote namespace for ourselves. Some users\n>>> might have already have branches heads/ant, heads/bee... making new\n>>> style detection unreliable.\n>\n> I don't quite follow the argument. For me the question is how likely\n> an old-time user has modified the refspec to read\n> \"refs/remotes/$remote/heads/* (new-style). I think this is very, very\n> unlikely and thus the \"heuristic\" to detect old/new style works most\n> of the time and there is no need for a new config/compatibility key.\n\nPersonally I don't have any repos that weird, so it's no problem to\nme. Maybe I'm overengineering.\n-- \nDuy\n"},{"id":"160412","messageId":"7vpqr7xw4z.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"201102020322.00171.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-04T22:39:08Z","receivedAt":"2011-02-04T22:39:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> - Remote tags are now stored separate from local tags. When looking up a \n> shorthand tag name (e.g. v1.7.4), we should consult local tags \n> (refs/tags/v1.7.4) before remote tags (refs/remotes/*/tags/v1.7.4 [1]). See \n> [2] for more details.\n\n> - Remote heads have moved into refs/remotes/$remote/heads/*, hence \n> invalidating shorthand remote head names, like \"origin/master\". We should \n> change the lookup code, so that a shorthand ref of the form \"$remote/$head\" \n> where \"$remote\" happens to match a configured remote is eventually expanded \n> into lookup for \"refs/remotes/$remote/heads/$head\" [3].\n\nKeeping 'origin/next' usable is a _must_, _if_ we were to go this route.\n\n> - We might want to generalize the handling of \"$remote/$head\" into allowing \n> shorthands like \"$remote/$tag\", \"$remote/$replace\" and \"$remote/$note\" as \n> well (provided, of course, that they match unambiguously).\n>\n> - All fetch refspecs should be given explicitly.\n\nWhat do you mean by this?\n\n> Sub-proposal: While we are changing the default refspecs, we should also \n> consider whether we want to keep the auto-following behavior that Git \n> currently does for tags (don't fetch tags that refer to objects not \n> otherwise fetched by another refspec). If we simply make an explicit \n> \"+refs/tags/*:refs/remotes/$remote/tags/*\" refspec, we will lose the auto-\n> following behavior. If we do want to keep the auto-following behavior, we \n> could for example add a \"~\" prefix to the refspec to trigger auto-following \n> behavior (i.e. this refspec only applies to refs that happen to point at \n> objects fetched by way of a different refspec). See \n> http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160795 \n> for more details.\n\nYou seem to envision \"auto-follow\" to slurp remote tags in remotes/origin/$tag\nnamespace. What should \"git fetch --tags $from_there\" do?\n\nFor some reason, many people seem to be enthused about splitting the tag\nnamespace, but I am not sure if that is a good thing in general. Branches\nare moving pointers for people to flip around in their local repositories,\nand it makes sense to say \"My master is a bit ahead of the public one\",\nbut what would we gain by making it _easier_ to add and exchange many tags\nwith the same name (e.g. refs/remotes/*/tags/v1.7.4 vs refs/tags/v1.7.4),\nother than the extra confusion?\n\nWhile you are talking about drastic reorganization (and rewriting the ref\ncode to support it), another possible Sub-proposal we may want to consider\nis to allow \"next\" and \"next/foo\" at the same time.\n"},{"id":"160420","messageId":"201102050218.44325.johan@herland.net","threadId":"26377","inReplyTo":"7vpqr7xw4z.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-05T01:18:44Z","receivedAt":"2011-02-05T01:18:44Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Friday 04 February 2011, Junio C Hamano wrote:\n> Johan Herland writes:\n> > - Remote heads have moved into refs/remotes/$remote/heads/*, hence\n> > invalidating shorthand remote head names, like \"origin/master\". We\n> > should change the lookup code, so that a shorthand ref of the form\n> > \"$remote/$head\" where \"$remote\" happens to match a configured remote\n> > is eventually expanded into lookup for\n> > \"refs/remotes/$remote/heads/$head\" [3].\n> \n> Keeping 'origin/next' usable is a _must_, _if_ we were to go this route.\n\nOf course.\n\n> > - All fetch refspecs should be given explicitly.\n> \n> What do you mean by this?\n\nToday, when you fetch from a remote, the config typically says\n\n[remote \"origin\"]\n fetch = +refs/heads/*:refs/remotes/origin/*\n url = ...\n\nBut this fetch refspec does not tell the full story. In addition to mapping \norigin's refs/heads/* into refs/remotes/origin/*, it also fetches origin's \nHEAD into refs/remotes/origin/HEAD, and anything in origin's refs/tags/* \nthat happen to point to a fetched object is fetched into refs/tags/* (aka. \nauto-following tags). These other fetches are not explicitly specified in \nthe config, but \"magically\" happen anyway. Instead of having such implicit \nrefspecs, I'd rather have all fetch refspecs listed explicitly in the \nconfig, like this (for replicating current layout):\n\n[remote \"origin\"]\n fetch = +HEAD:refs/remotes/origin/HEAD\n fetch = +refs/heads/*:refs/remotes/origin/*\n fetch = ~refs/tags/*:refs/tags/*\n url = ...\n\nor this (in the proposed new layout):\n\n[remote \"origin\"]\n fetch = +HEAD:refs/remotes/origin/HEAD\n fetch = +refs/heads/*:refs/remotes/origin/heads*\n fetch = +refs/tags/*:refs/remotes/origin/tags/*\n url = ...\n\n> > Sub-proposal: While we are changing the default refspecs, we should\n> > also consider whether we want to keep the auto-following behavior that\n> > Git currently does for tags (don't fetch tags that refer to objects\n> > not otherwise fetched by another refspec). If we simply make an\n> > explicit \"+refs/tags/*:refs/remotes/$remote/tags/*\" refspec, we will\n> > lose the auto- following behavior. If we do want to keep the\n> > auto-following behavior, we could for example add a \"~\" prefix to the\n> > refspec to trigger auto-following behavior (i.e. this refspec only\n> > applies to refs that happen to point at objects fetched by way of a\n> > different refspec). See\n> > http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160\n> > 795 for more details.\n> \n> You seem to envision \"auto-follow\" to slurp remote tags in\n> remotes/origin/$tag namespace. What should \"git fetch --tags $from_there\"\n> do?\n\nI would propose that \"git fetch --tags $from_there\" follows these steps:\n\n1. Enumerate the (implicit or explicit) fetch refspecs for the given remote.\n\n2. Map \"refs/tags/*\" through the refspecs to find where the remote tags \nshould be stored in the local repo.\n\n3. If the matching refspec starts with \"~\" (auto-following), disregard the \n\"~\" (since --tags disables auto-following).\n\n4. Slurp remote tags into the location found in step #2.\n\nSince we map through the refspec, the remote tags end up where the user \nexpect to find them: in refs/tags/* for old-style remotes, or in \nrefs/remotes/$from_there/tags/* for new-style remotes.\n\n> For some reason, many people seem to be enthused about splitting the tag\n> namespace, but I am not sure if that is a good thing in general. \n> Branches are moving pointers for people to flip around in their local\n> repositories, and it makes sense to say \"My master is a bit ahead of the\n> public one\", but what would we gain by making it _easier_ to add and\n> exchange many tags with the same name (e.g. refs/remotes/*/tags/v1.7.4\n> vs refs/tags/v1.7.4), other than the extra confusion?\n\nFirst, I should state that making tags into moving pointers is not something \nI support, nor is it part of this proposal. Tags should still very much \nrefuse to be moved (except when forced).\n\nHaving said that, there are real situations where users encounter collisions \nin the shared tag namespace. A rare (but plausible) scenario arise when two \ndevelopers create (and publish) conflicting tags in their repos. A more \ncommon scenario that I have encountered at $dayjob, is where two parallel \n(semi-related) projects are developed in separate repos (with different \nversioning because of separate release schedules), and I need to interface \nwith both repos from a single local repo. Each of the remote repos have \ntheir own \"v1.0\" tag, but my repo can only hold one such tag. Which of those \ntags end up \"winning\" in my local repo depends on my fetch order.\n\nGit already has code to discover ambiguous ref names, and we have powerful \ntools for inspecting the history and diffs between local and remote \nbranches. But because we conflate tags into a single namespace, we cannot \neasily use these tools when circumstances conspire to produce conflicting \ntags.\n\nPutting remote tags into separate namespaces allows us to use the same tools \nthat we use on remote branches, to discover and inspect conflicting tags \nwhen (if only rarely) they do happen.\n\nAnother advantage of splitting tags into separate namespaces is that the \n\"source\" or \"domain\" of a tag becomes slightly less foggy: Consider a tag \n\"foo\" that may exist as refs/remotes/origin/tags/foo (remote/public) and/or \nas refs/tags/foo (local/private). If it exists only locally, it may be a \nhint that this is a \"private\" tag (not intended for public consumption). If \nit exists only remotely, it's obviously a public tag. If it exists both \nlocally and remotely (without conflict), it may indicate that this is a \npublic tag that was originally created in this repo.\n\n> While you are talking about drastic reorganization (and rewriting the ref\n> code to support it), another possible Sub-proposal we may want to\n> consider is to allow \"next\" and \"next/foo\" at the same time.\n\nInteresting. I haven't followed this discussion lately (if there has been \nany), but I guess we need to find a new way to organize loose refs that \ndoesn't cause file vs. directory problems. Obviously, the packed-refs format \nshould have no inherent problem with these refs, but I guess we can't drop \nloose ref support completely.\n\nOne sort-of-workaround could be to detect when \"next\" vs. \"next/foo\" \nhappens, and simply force one of them to be a packed ref.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160451","messageId":"4D4D9054.8040906@digium.com","threadId":"26377","inReplyTo":"201102050218.44325.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Kevin P. Fleming","fromEmail":"kpfleming@digium.com","sentAt":"2011-02-05T18:00:52Z","receivedAt":"2011-02-05T18:00:52Z","isPatch":false,"sender":{"key":"kpfleming@digium.com","avatar":null},"body":"On 02/05/2011 02:18 AM, Johan Herland wrote:\n\n> Today, when you fetch from a remote, the config typically says\n>\n> [remote \"origin\"]\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> url = ...\n>\n> But this fetch refspec does not tell the full story. In addition to mapping\n> origin's refs/heads/* into refs/remotes/origin/*, it also fetches origin's\n> HEAD into refs/remotes/origin/HEAD, and anything in origin's refs/tags/*\n> that happen to point to a fetched object is fetched into refs/tags/* (aka.\n> auto-following tags). These other fetches are not explicitly specified in\n> the config, but \"magically\" happen anyway. Instead of having such implicit\n> refspecs, I'd rather have all fetch refspecs listed explicitly in the\n> config, like this (for replicating current layout):\n>\n> [remote \"origin\"]\n> fetch = +HEAD:refs/remotes/origin/HEAD\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> fetch = ~refs/tags/*:refs/tags/*\n> url = ...\n>\n> or this (in the proposed new layout):\n>\n> [remote \"origin\"]\n> fetch = +HEAD:refs/remotes/origin/HEAD\n> fetch = +refs/heads/*:refs/remotes/origin/heads*\n> fetch = +refs/tags/*:refs/remotes/origin/tags/*\n> url = ...\n\nI would appreciate this as well; the less implicit behavior in areas \nlike this, the better :-)\n\n-- \nKevin P. Fleming\nDigium, Inc. | Director of Software Technologies\n445 Jan Davis Drive NW - Huntsville, AL 35806 - USA\nskype: kpfleming | jabber: kfleming@digium.com\nCheck us out at www.digium.com & www.asterisk.org\n"},{"id":"160456","messageId":"alpine.LFD.2.00.1102051330270.12104@xanadu.home","threadId":"26377","inReplyTo":"7vpqr7xw4z.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-05T18:39:57Z","receivedAt":"2011-02-05T18:39:57Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 4 Feb 2011, Junio C Hamano wrote:\n\n> For some reason, many people seem to be enthused about splitting the tag\n> namespace, but I am not sure if that is a good thing in general. Branches\n> are moving pointers for people to flip around in their local repositories,\n> and it makes sense to say \"My master is a bit ahead of the public one\",\n> but what would we gain by making it _easier_ to add and exchange many tags\n> with the same name (e.g. refs/remotes/*/tags/v1.7.4 vs refs/tags/v1.7.4),\n> other than the extra confusion?\n\nThe extraordinary misfeature of the tag namespace at the moment comes \nfrom the fact that whenever you add a remote repo to fetch, and do fetch \nit, then your flat tag namespace gets polluted with all the tags the \nremote might have. If you decide to delete some of those remote \nbranches, the tags that came with it are still there and \nindistinguishable from other tags making it a real pain to sort out.\n\nSo that's what has to be fixed. If you get duplicated tag names then \njust warn the user and give priority to the local one, or error out with \na \"ambiguous tag specification\" if no local but multiple remote tags \nwith the same name are found (the user would have to be more precise in \nthe tag scope in that case).\n\n\nNicolas\n"},{"id":"160464","messageId":"20110205193708.GA2192@sigill.intra.peff.net","threadId":"26377","inReplyTo":"alpine.LFD.2.00.1102051330270.12104@xanadu.home","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-05T19:37:09Z","receivedAt":"2011-02-05T19:37:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 05, 2011 at 01:39:57PM -0500, Nicolas Pitre wrote:\n\n> So that's what has to be fixed. If you get duplicated tag names then \n> just warn the user and give priority to the local one, or error out with \n> a \"ambiguous tag specification\" if no local but multiple remote tags \n> with the same name are found (the user would have to be more precise in \n> the tag scope in that case).\n\nThe latter seems like a regression for the common case of fetching from\ntwo upstreams. E.g., I usually pull from Junio, getting\nremotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I\npull from him, getting remotes/spearce/v1.7.0, which he previously\nfetched from Junio. Under the current code, I can still do \"git show\nv1.7.0\"; under the scheme described above I now have to say\n\"origin/v1.7.0\" to disambiguate.\n\nThe real issue, I think, is that we are claiming ambiguity even though\nthose tags almost certainly point to the same sha1. When handling\nambiguous tags, should we perhaps check to see if all of the ambiguities\npoint to the same sha1, and in that case, just pick one at random?\n\nIn the case of resolving a ref to a sha1, then by definition they are\nall equivalent to pick. For things that care (e.g., \"git checkout\") we\nshould probably still complain (although many of those commands have\ntheir own disambiguation code to prefer refs/heads/ or whatever anyway).\n\n-Peff\n"},{"id":"160465","messageId":"alpine.LFD.2.00.1102051449420.12104@xanadu.home","threadId":"26377","inReplyTo":"20110205193708.GA2192@sigill.intra.peff.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-05T19:55:06Z","receivedAt":"2011-02-05T19:55:06Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 5 Feb 2011, Jeff King wrote:\n\n> On Sat, Feb 05, 2011 at 01:39:57PM -0500, Nicolas Pitre wrote:\n> \n> > So that's what has to be fixed. If you get duplicated tag names then \n> > just warn the user and give priority to the local one, or error out with \n> > a \"ambiguous tag specification\" if no local but multiple remote tags \n> > with the same name are found (the user would have to be more precise in \n> > the tag scope in that case).\n> \n> The latter seems like a regression for the common case of fetching from\n> two upstreams. E.g., I usually pull from Junio, getting\n> remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I\n> pull from him, getting remotes/spearce/v1.7.0, which he previously\n> fetched from Junio. Under the current code, I can still do \"git show\n> v1.7.0\"; under the scheme described above I now have to say\n> \"origin/v1.7.0\" to disambiguate.\n\nLet's suppose that both tags are identical, as in your scenario above \nthey would be, then there is no need to call for any ambiguity in that \ncase.\n\n> The real issue, I think, is that we are claiming ambiguity even though\n> those tags almost certainly point to the same sha1. When handling\n> ambiguous tags, should we perhaps check to see if all of the ambiguities\n> point to the same sha1, and in that case, just pick one at random?\n\nIf they're identical then there is no randomness. If they refer to \ndifferent tag objects, even if those tag objects do refer to the same \ncommit object, then I'd say there is an ambiguity only if the tag object \ncontent matters i.e. when displaying the tag content.\n\n> In the case of resolving a ref to a sha1, then by definition they are\n> all equivalent to pick. For things that care (e.g., \"git checkout\") we\n> should probably still complain (although many of those commands have\n> their own disambiguation code to prefer refs/heads/ or whatever anyway).\n\nWe are probably more or less saying the same thing.\n\n\nNicolas\n"},{"id":"160466","messageId":"20110205214045.GA15668@dpotapov.dyndns.org","threadId":"26377","inReplyTo":"201102050218.44325.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-02-05T21:40:45Z","receivedAt":"2011-02-05T21:40:45Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sat, Feb 05, 2011 at 02:18:44AM +0100, Johan Herland wrote:\n> On Friday 04 February 2011, Junio C Hamano wrote:\n> \n> > For some reason, many people seem to be enthused about splitting the tag\n> > namespace, but I am not sure if that is a good thing in general. \n> > Branches are moving pointers for people to flip around in their local\n> > repositories, and it makes sense to say \"My master is a bit ahead of the\n> > public one\", but what would we gain by making it _easier_ to add and\n> > exchange many tags with the same name (e.g. refs/remotes/*/tags/v1.7.4\n> > vs refs/tags/v1.7.4), other than the extra confusion?\n> \n> First, I should state that making tags into moving pointers is not something \n> I support, nor is it part of this proposal. Tags should still very much \n> refuse to be moved (except when forced).\n> \n> Having said that, there are real situations where users encounter collisions \n> in the shared tag namespace. A rare (but plausible) scenario arise when two \n> developers create (and publish) conflicting tags in their repos. A more \n> common scenario that I have encountered at $dayjob, is where two parallel \n> (semi-related) projects are developed in separate repos (with different \n> versioning because of separate release schedules), and I need to interface \n> with both repos from a single local repo. Each of the remote repos have \n> their own \"v1.0\" tag, but my repo can only hold one such tag. Which of those \n> tags end up \"winning\" in my local repo depends on my fetch order.\n\nWell, I agree that this situation requires a better diagnostic, but I\ndon't think that having separate namespaces is the right solution in\ngeneral. For your case, where you work on semi-related projects, it is\ncould be the right thing to do, but if you work on the same project and\nhave more than one source to fetch, then having multiple namespaces can\nlead only to confusion, because tag names must be unique globally to\nmake sense to everyone. Actually, even if you have two semi-related\nprojects in the same repository, but you have more than one URL per\nproject, you want to group tags based on their relation to the project\nand not based on the URL.\n\n\nDmitry\n"},{"id":"160477","messageId":"201102060039.57588.johan@herland.net","threadId":"26377","inReplyTo":"alpine.LFD.2.00.1102051449420.12104@xanadu.home","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-05T23:39:57Z","receivedAt":"2011-02-05T23:39:57Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Saturday 05 February 2011, Nicolas Pitre wrote:\n> On Sat, 5 Feb 2011, Jeff King wrote:\n> > On Sat, Feb 05, 2011 at 01:39:57PM -0500, Nicolas Pitre wrote:\n> > > So that's what has to be fixed. If you get duplicated tag names then\n> > > just warn the user and give priority to the local one, or error out\n> > > with a \"ambiguous tag specification\" if no local but multiple remote\n> > > tags with the same name are found (the user would have to be more\n> > > precise in the tag scope in that case).\n> > \n> > The latter seems like a regression for the common case of fetching from\n> > two upstreams. E.g., I usually pull from Junio, getting\n> > remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I\n> > pull from him, getting remotes/spearce/v1.7.0, which he previously\n> > fetched from Junio. Under the current code, I can still do \"git show\n> > v1.7.0\"; under the scheme described above I now have to say\n> > \"origin/v1.7.0\" to disambiguate.\n> \n> Let's suppose that both tags are identical, as in your scenario above\n> they would be, then there is no need to call for any ambiguity in that\n> case.\n> \n> > The real issue, I think, is that we are claiming ambiguity even though\n> > those tags almost certainly point to the same sha1. When handling\n> > ambiguous tags, should we perhaps check to see if all of the\n> > ambiguities point to the same sha1, and in that case, just pick one at\n> > random?\n> \n> If they're identical then there is no randomness. If they refer to\n> different tag objects, even if those tag objects do refer to the same\n> commit object, then I'd say there is an ambiguity only if the tag object\n> content matters i.e. when displaying the tag content.\n> \n> > In the case of resolving a ref to a sha1, then by definition they are\n> > all equivalent to pick. For things that care (e.g., \"git checkout\") we\n> > should probably still complain (although many of those commands have\n> > their own disambiguation code to prefer refs/heads/ or whatever\n> > anyway).\n> \n> We are probably more or less saying the same thing.\n\nYes, I believe this was all covered by a footnote in my proposal. Quote:\n\n[2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local tag \n(refs/tags/v1.7.4) is found, then we have an unambiguous match. If no local \ntag is found, we look up the tag name in all configured remotes (using the \nmethod described in [1]). If the tag name exists in one or more remotes, and \nthose remotes all agree on its ultimate object name (after applying e.g. \n^{commit} or whatever is appropriate in the context of the lookup), then we \nalso have an unambiguous match. However, if the tag name exists in multiple \nremotes, and they do NOT all agree on its ultimate object name, then the \nshorthand tag name is ambiguous and the lookup fails. The user can always \nresolve this ambiguity by creating a local tag (refs/tags/v1.7.4) pointing \nto the desired object.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160479","messageId":"201102060104.37146.johan@herland.net","threadId":"26377","inReplyTo":"20110205214045.GA15668@dpotapov.dyndns.org","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-06T00:04:36Z","receivedAt":"2011-02-06T00:04:36Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Saturday 05 February 2011, Dmitry Potapov wrote:\n> On Sat, Feb 05, 2011 at 02:18:44AM +0100, Johan Herland wrote:\n> > Having said that, there are real situations where users encounter\n> > collisions in the shared tag namespace. A rare (but plausible)\n> > scenario arise when two developers create (and publish) conflicting\n> > tags in their repos. A more common scenario that I have encountered at\n> > $dayjob, is where two parallel (semi-related) projects are developed\n> > in separate repos (with different versioning because of separate\n> > release schedules), and I need to interface with both repos from a\n> > single local repo. Each of the remote repos have their own \"v1.0\" tag,\n> > but my repo can only hold one such tag. Which of those tags end up\n> > \"winning\" in my local repo depends on my fetch order.\n> \n> Well, I agree that this situation requires a better diagnostic, but I\n> don't think that having separate namespaces is the right solution in\n> general. For your case, where you work on semi-related projects, it is\n> could be the right thing to do, but if you work on the same project and\n> have more than one source to fetch, then having multiple namespaces can\n> lead only to confusion, because tag names must be unique globally to\n> make sense to everyone. Actually, even if you have two semi-related\n> projects in the same repository, but you have more than one URL per\n> project, you want to group tags based on their relation to the project\n> and not based on the URL.\n\nI'm not sure what problem you're describing here. Let's assume that my repo \nhas multiple remotes (URLs), but they're all fundamentally part of the same \nproject. If there is a tag \"foo\" in one remote/namespace, and a tag \"foo\" in \na different remote/namespace, they (in the common case) point to the same \nobject, since they - as you say - \"must be unique globally to make sense to \neveryone\".\n\nAs long as they point to the same object, there's no ambiguity, and when you \nsimply refer to tag \"foo\" (without specifying namespace) it all works, like \ntoday. (Read footnote [2] of my proposal for more details on handling \nambiguity in tag names.)\n\nHowever, when the remote tags point to different objects (i.e. the uncommon \ncase), there is an ambiguity, and we should deal with that ambiguity \nproperly, instead of silently adopting one of them arbitrarily.\n\nI don't see how the separate namespaces cause problems here. Also, I don't \nknow what you're proposing instead, or indeed what other organization of \ntags would lead to less confusion.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160491","messageId":"AANLkTikmD8qZOE+hi1=aeeVJx2qQpzdm0tV1mLsx1tfB@mail.gmail.com","threadId":"26377","inReplyTo":"201102060104.37146.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-02-06T12:03:02Z","receivedAt":"2011-02-06T12:03:02Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Feb 06, 2011 at 01:04:36AM +0100, Johan Herland wrote:\n>_\n> As long as they point to the same object, there's no ambiguity, and when you_\n> simply refer to tag \"foo\" (without specifying namespace) it all works, like_\n> today. (Read footnote [2] of my proposal for more details on handling_\n> ambiguity in tag names.)\n\nI see no reason to create different namespaces, because semantically\nthere is only one namespace.\n\n> However, when the remote tags point to different objects (i.e. the uncommon_\n> case), there is an ambiguity, and we should deal with that ambiguity_\n> properly, instead of silently adopting one of them arbitrarily.\n\nTo me, the proper handling ambiguity means that when I do \"git fetch\" I\nimmediately see warning about tag clashes. So, I agree with you that\ncurrent behavior is not good, but I disagree with you about having many\nnamespaces, because it postpones detection of the conflict until I try\nto use. And well, git may detect ambiguity when I say \"git show v1.0\",\nbut if I look at my branch in gitk and see \"v1.0\" and may say to someone\nthat I use \"v1.0\" but that person looks at his tree and sees \"v1.0\" as\nsomething different.\n\nSo, if there is two different tags with the same name, it is better to\nreport the problem as soon as possible, i.e. during \"git fetch\", and\nthen there is no reason to have separate namespaces for tags.\n\nDmitry\n"},{"id":"160493","messageId":"alpine.LFD.2.00.1102060900570.12104@xanadu.home","threadId":"26377","inReplyTo":"AANLkTikmD8qZOE+hi1=aeeVJx2qQpzdm0tV1mLsx1tfB@mail.gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-06T14:09:26Z","receivedAt":"2011-02-06T14:09:26Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 6 Feb 2011, Dmitry Potapov wrote:\n\n> To me, the proper handling ambiguity means that when I do \"git fetch\" I\n> immediately see warning about tag clashes.\n\nFair enough.\n\n> So, I agree with you that\n> current behavior is not good, but I disagree with you about having many\n> namespaces, because it postpones detection of the conflict until I try\n> to use.\n\nNo. The later does not prevent the former.\n\n> And well, git may detect ambiguity when I say \"git show v1.0\",\n> but if I look at my branch in gitk and see \"v1.0\" and may say to someone\n> that I use \"v1.0\" but that person looks at his tree and sees \"v1.0\" as\n> something different.\n\nIf gitk is smart enough to see that two tags have the same name then it \nshould scope them so they are not ambiguous anymore, unless of course \nthey are referring to the same thing in which case they are not \nambiguous from the start.\n\n> So, if there is two different tags with the same name, it is better to\n> report the problem as soon as possible, i.e. during \"git fetch\", and\n> then there is no reason to have separate namespaces for tags.\n\nOf course there is a reason. What if your fetch brings in hundreds of \ntags (this is common for some projects) and then you want to remove that \nfetched branch from your repository? How do you determine which tag \ncame from that remote repository and which tags are to be kept? Without \na separate namespace this is practically impossible.\n\n\nNicolas\n"},{"id":"160496","messageId":"AANLkTinDmCZH95jidJ1NYFRd8X_xNehyrhA8hBcx5=SR@mail.gmail.com","threadId":"26377","inReplyTo":"alpine.LFD.2.00.1102060900570.12104@xanadu.home","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-02-06T15:17:07Z","receivedAt":"2011-02-06T15:17:07Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Feb 06, 2011 at 09:09:26AM -0500, Nicolas Pitre wrote:\n> On Sun, 6 Feb 2011, Dmitry Potapov wrote:\n>_\n> > To me, the proper handling ambiguity means that when I do \"git fetch\" I\n> > immediately see warning about tag clashes.\n>_\n> Fair enough.\n>_\n> > So, I agree with you that\n> > current behavior is not good, but I disagree with you about having many\n> > namespaces, because it postpones detection of the conflict until I try\n> > to use.\n>_\n> No. The later does not prevent the former.\n\nBut what if I really have two semi-related projects that I want to fetch\ninto the same repository as Johan suggested? In this case, I want to\nhave separate namespaces and no warning when I fetch.\n\n>_\n> Of course there is a reason. What if your fetch brings in hundreds of_\n> tags (this is common for some projects) and then you want to remove that_\n> fetched branch from your repository? How do you determine which tag_\n> came from that remote repository and which tags are to be kept? Without_\n> a separate namespace this is practically impossible.\n\nWell, I see your use case now. Maybe the right solution is add an option\nthat will tell whether to fetch tags into separate namespace or not, and\nlater based on experiences, we can decide whether we want to change the\ndefault to have separate namespaces for tags.\n\n\nDmitry\n"},{"id":"160498","messageId":"201102061711.45460.johan@herland.net","threadId":"26377","inReplyTo":"AANLkTikmD8qZOE+hi1=aeeVJx2qQpzdm0tV1mLsx1tfB@mail.gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-06T16:11:45Z","receivedAt":"2011-02-06T16:11:45Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sunday 06 February 2011, Dmitry Potapov wrote:\n> On Sun, Feb 06, 2011 at 01:04:36AM +0100, Johan Herland wrote:\n> >_\n> >\n> > As long as they point to the same object, there's no ambiguity, and\n> > when you_ simply refer to tag \"foo\" (without specifying namespace) it\n> > all works, like_ today. (Read footnote [2] of my proposal for more\n> > details on handling_ ambiguity in tag names.)\n> \n> I see no reason to create different namespaces, because semantically\n> there is only one namespace.\n\nIn practice, there is almost always one namespace (i.e. your repo belongs to \nonly one project with project-wide unique tags). However, in any distributed \nsystem, the only-one-namespace is fundamentally a myth. Sure, it's a \nconvenient myth, and one that we - with good reason - strive towards \nfulfilling, but there are situations (described earlier in this thread) \nwhere the myth is busted. In those situations, I think the _least_ confusing \nthing we can do for our users is to handle all remote refs consistently, and \nallow them to discover/investigate the remote tags as they would other \nremote refs.\n\n> > However, when the remote tags point to different objects (i.e. the\n> > uncommon_ case), there is an ambiguity, and we should deal with that\n> > ambiguity_ properly, instead of silently adopting one of them\n> > arbitrarily.\n> \n> To me, the proper handling ambiguity means that when I do \"git fetch\" I\n> immediately see warning about tag clashes. So, I agree with you that\n> current behavior is not good, but I disagree with you about having many\n> namespaces, because it postpones detection of the conflict until I try\n> to use. And well, git may detect ambiguity when I say \"git show v1.0\",\n> but if I look at my branch in gitk and see \"v1.0\" and may say to someone\n> that I use \"v1.0\" but that person looks at his tree and sees \"v1.0\" as\n> something different.\n\nIn that case it would be wrong of gitk to display \"v1.0\". Instead it should \ndisplay a longer, unambiguous name, e.g. \"origin/v1.0\".\n\n> So, if there is two different tags with the same name, it is better to\n> report the problem as soon as possible, i.e. during \"git fetch\", and\n> then there is no reason to have separate namespaces for tags.\n\nYes, that is an alternative solution for tags. I guess it comes down to a \nquestion of how much special treatment we want to give tags. I'd rather have \nconsistency between how tags and other remote refs are handled.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160504","messageId":"AANLkTi=gd5iu0i=ggqJC++N_rL+nU6RO9PNw=jMpT0NH@mail.gmail.com","threadId":"26377","inReplyTo":"201102061711.45460.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-02-06T17:28:26Z","receivedAt":"2011-02-06T17:28:26Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Feb 06, 2011 at 05:11:45PM +0100, Johan Herland wrote:\n> On Sunday 06 February 2011, Dmitry Potapov wrote:\n> > On Sun, Feb 06, 2011 at 01:04:36AM +0100, Johan Herland wrote:\n> > >_\n> > >\n> > > As long as they point to the same object, there's no ambiguity, and\n> > > when you_ simply refer to tag \"foo\" (without specifying namespace) it\n> > > all works, like_ today. (Read footnote [2] of my proposal for more\n> > > details on handling_ ambiguity in tag names.)\n> >_\n> > I see no reason to create different namespaces, because semantically\n> > there is only one namespace.\n>_\n> In practice, there is almost always one namespace (i.e. your repo belongs to_\n> only one project with project-wide unique tags). However, in any distributed_\n> system, the only-one-namespace is fundamentally a myth.\n\nBy your logic git 1.7.4 is a myth, because I have not specified from\nwhat repository I pull it. But, IMHO, it is a myth that having different\nnamespaces solves the problem, because in _most_ cases, you really want\nto have a single namespace _semantically_, so you can communicate with\nother people using this tag name. In your case of semi-related projects,\nit should be two namespaces, because there are _two_ different projects\n(even if they share a lot of common history). How do I know that they\nare different? Because they have different release schedulers, and v1.0\nmeans different for each of them.\n\n> > To me, the proper handling ambiguity means that when I do \"git fetch\" I\n> > immediately see warning about tag clashes. So, I agree with you that\n> > current behavior is not good, but I disagree with you about having many\n> > namespaces, because it postpones detection of the conflict until I try\n> > to use. And well, git may detect ambiguity when I say \"git show v1.0\",\n> > but if I look at my branch in gitk and see \"v1.0\" and may say to someone\n> > that I use \"v1.0\" but that person looks at his tree and sees \"v1.0\" as\n> > something different.\n>_\n> In that case it would be wrong of gitk to display \"v1.0\". Instead it should_\n> display a longer, unambiguous name, e.g. \"origin/v1.0\".\n\nBut it is still ambiguous because my \"origin\" may be different from\nyours origin. It is only unambiguous when it look at it _locally_ but\nthat makes it completely useless for communication with other people.\nOne project should have only one version with the same tag regardless\nwhere it came from.\n\nI agree in your use case of semi-related projects you need separate\nnamespaces. But I don't think it is how most people use git. It may\nbe nice to have an option that will make tag namespace separate, but\nI do not think it should be default. Not until, it is widely tested.\n\n\nDmitry\n"},{"id":"160543","messageId":"7vvd0xvsjc.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"alpine.LFD.2.00.1102051449420.12104@xanadu.home","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-06T20:04:23Z","receivedAt":"2011-02-06T20:04:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n>> The latter seems like a regression for the common case of fetching from\n>> two upstreams. E.g., I usually pull from Junio, getting\n>> remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I\n>> pull from him, getting remotes/spearce/v1.7.0, which he previously\n>> fetched from Junio. Under the current code, I can still do \"git show\n>> v1.7.0\"; under the scheme described above I now have to say\n>> \"origin/v1.7.0\" to disambiguate.\n>\n> Let's suppose that both tags are identical, as in your scenario above \n> they would be, then there is no need to call for any ambiguity in that \n> case.\n\nI agree that we do not want refs/remotes/tags/*/that-tag-people-agree-on\nin that case. We want to store a single copy and find it there, and that\nsingle copy has traditionally been found in refs/tags hierarchy.\n\nI think the real issue is not necessarily that the location is shared with\nlocal tag namespace, but is the lack of a convenient way (or just BCP) to\nsegregate what are local and what are official when transferring tags out\nof your repository. That is what discourages people from using tags for\ntheir personal and ephemeral use, marking some points in their own work\nwith personal tags that are never intended to be published.\n\nIn the \"interim maintainer\" case without separate tag namespaces, Shawn\nwould have been using refs/tags space to auto-follow vX.Y.Z tags that\neverybody agrees on and also mark his own progress with local tags, and he\nneeds to be careful not to push out the local tags he does not want to\nshare to his publishing repository, lest he contaminate refs/tags in\nrepositories of other people [*1*]\n\nBut the above is less of an issue, for people who use a separate publish\nrepository with private working repository. All they need to do is to be\ncareful when they run \"git push\". By default we don't push new tags\n(thanks to \"matching refs\") nor push autopropagates tags when pushing\nupdated branch heads out, so it suffices only to double check the tag\nbeing pushed is the right one when they run \"git push $there vX.Y.Z\", and\nto make sure they never run \"git push --tags\".\n\nThe problem happens when people directly start fetching or cloning from a\nprivate working-space repository, e.g. my primary integration repository\nhas several tags that shouldn't go to k.org mixed with the vX.Y.Z tags,\nand that is perfectly fine as the organization gives me a uniform way to\ncall things with names without looking at many places (i.e. refs/tags vs\nrefs/remotes/*/tags/), yet it does not risk contaminating other people's\ntag namespaces because I don't allow anybody to clone nor fetch from it\ndirectly. That breaks down once people can fetch/clone from it.\n\nThinking aloud and not thinking things through, perhaps what's needed is a\nnamespace private/local to the repository, i.e. instead of\nrefs/remotes/*/tags, refs/private-tags hierarchy that I can use to store\nlocal names, and are never seen by fetch/clone?\n\nYou can swap naming around and say my (refs/tags, refs/private-tags) can\nbe expressed with (refs/remotes/origin/tags, refs/tags), and I fully agree\nwith that argument. The former is for tags everybody agrees on, the\nlatter for tags that are private. The aversion I showed in my message\nagainst refs/remotes/*/tags is coming directly from this observation.\n\nNamely, you can explain refs/remotes/origin/tags with the above line of\nreasoning, but how would you explain refs/remotes/$other_names/tags\nhierarchy? What do they mean, how they are useful, etc.\n\n\n\n[Footnote]\n\n*1* This issue actually is already present without \"interim maintainer\".\nI have several tags in my primary integration repository that I don't\nintend to publish to my repository at k.org; the gitster/git.git\nrepository I have at GitHub is intended to disclose what I personally\nhave, including the broken-out set of topic branches, and these tags are\npublished there.\n"},{"id":"160545","messageId":"vpqaai8oqkc.fsf@bauges.imag.fr","threadId":"26377","inReplyTo":"201102060104.37146.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-06T20:28:51Z","receivedAt":"2011-02-06T20:28:51Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johan Herland writes:\n\n> I don't see how the separate namespaces cause problems here. Also, I don't \n> know what you're proposing instead, or indeed what other organization of \n> tags would lead to less confusion.\n\nI'm not against the idea, but one drawback of the separate namespace\nis that it introduces complexity for the user. In the common case,\nwhere the user may fetch the same tag from various sources, there \nwill still be several refs (probably listed by \"git tag\" ?), and this\nmay confuse the user.\n\nAnother question is what happens when you push. With branches,\nfetching XXX fetches in origin/XXX, but pushing YYY does push to YYY.\nThis asymetry between push and pull works well because most of the\ntime, if we have a origin/XXX branch, we also have XXX (with\norigin/XXX as upstream).\n\nFor tags, it's clearly different. If I have origin/v1.7.4, I don't see\nmuch reason to have _also_ v1.7.4 as a local tag. And if I have only\norigin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from\nit will get origin/origin/v1.7.4, and so on.\n\nSo, my feeling is that the \"separate namespace\" should not be\nautomatic.\n\nFor example, today, git.git repo contains tags like v1.7.4 and others\nlike gitgui-0.13.0, which is clearly a handmade namespace, where a\nreal namespace would be better. That would make a lot of sence to me\nif Junio had something like\n\n[remote \"git-gui\"]\n\turl = ...\n\tfetch = +refs/heads/*:refs/remotes/git-gui/*\n\tfetch = +refs/tags/*:refs/tags/remotes/git-gui/*\n\nor whatever other syntax, so that git-gui's tags be automatically\nfetched into the right namespace (with no warning in case of\nduplicate).\n\nBut OTOH, I don't want to have several namespaces in my git repo even\nif I configure several remotes to fetch from. In this case, duplicate\ntags are just redundancy if they point to the same object, and a real\nconflict I want to know about immediately otherwise.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160555","messageId":"201102062312.51655.johan@herland.net","threadId":"26377","inReplyTo":"AANLkTi=gd5iu0i=ggqJC++N_rL+nU6RO9PNw=jMpT0NH@mail.gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-06T22:12:51Z","receivedAt":"2011-02-06T22:12:51Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sunday 06 February 2011, Dmitry Potapov wrote:\n> On Sun, Feb 06, 2011 at 05:11:45PM +0100, Johan Herland wrote:\n> > In practice, there is almost always one namespace (i.e. your repo\n> > belongs to_ only one project with project-wide unique tags). However,\n> > in any distributed_ system, the only-one-namespace is fundamentally a\n> > myth.\n> \n> By your logic git 1.7.4 is a myth, because I have not specified from\n> what repository I pull it.\n\nYes, technically git 1.7.4 is a myth. However, by convention, we all agree \nwhat \"v1.7.4\" points to, and nobody seriously believe they can get away with \npointing \"v1.7.4\" somewhere else.\n\nThe core of this discussion is where we want to place Git in the space \nbetween \"technically correct\" and \"socially conventional\", where the former \nmeans owning up to the fact that each repo really is its own namespace, and \nthere's no way around that in a proper DVCS, and the latter means building \nsocial convention into our tools, thereby making it harder to deal with the \nfew unconventional cases (like my two semi-related repos case).\n\nAFAICS, my proposal does not harm the common case (unambiguous tags are \nstill interpreted unambiguously, even if they may exist in multiple \nnamespaces), while it _does_ help the uncommon case (by allowing ambiguous \ntags to co-exist in the same repo).\n\nGranted, if we leave all tags in a single namespace, I can still work around \nthis by manually futzing with the configured refspecs to create ad hoc \nnamespaces. But I _really_ hate it when I'm forced to hack around the tool, \nbecause the tool thinks it \"knows better\".\n\n> But, IMHO, it is a myth that having different\n> namespaces solves the problem, because in _most_ cases, you really want\n> to have a single namespace _semantically_, so you can communicate with\n> other people using this tag name.\n\nMy proposal tries very hard to present a single namespace _semantically_ to \nthe user in the common case (when tags are unambiguous). I'd even go as far \nas proposing that \"git tag -l\" should by default list only a single \nshortened tag name in the cases where there are multiple unambiguous \nalternatives.\n\nAlternatively, I'd suggest a compromise (already mentioned elsewhere in this \nthread) where we add a config variable tags.preferredRemote (defaults to \n\"origin\") which allows you to directly select which namespace you consider \nofficial. You could even implement this as physically copying \nrefs/remotes/${tag.preferredRemote}/tags/* into refs/tags/*.\n\n> > In that case it would be wrong of gitk to display \"v1.0\". Instead it\n> > should_ display a longer, unambiguous name, e.g. \"origin/v1.0\".\n> \n> But it is still ambiguous because my \"origin\" may be different from\n> yours origin. It is only unambiguous when it look at it _locally_ but\n> that makes it completely useless for communication with other people.\n> One project should have only one version with the same tag regardless\n> where it came from.\n\nAgain, you are setting \"technical correctness\" up against \"social \nconvention\". Technically, _any_ ref name whatsoever is repo-specific and \n\"completely useless for communication with other people\". The only thing we \ncan communicate unambiguously is SHA-1 object names. However, social \nconventions compel us to name our refs unambiguously and to use common sense \nwhen communicating, so that - in practice - everybody in the project knows \nexactly what is meant by \"v1.0\".\n\nIt seems our opinions differ on whether Git should try to _force_ this \nsocial convention on you, or rather stick to technical correctness (with a \nbias towards conventional behavior as long as there no ambiguities).\n\n> I agree in your use case of semi-related projects you need separate\n> namespaces. But I don't think it is how most people use git. It may\n> be nice to have an option that will make tag namespace separate, but\n> I do not think it should be default. Not until, it is widely tested.\n\nWell, this _is_ the thread for discussing things \"we would have done \ndifferently if we were writing Git from scratch\". ;)\n\nStill, you have yet to convince me exactly _what_ will in practice be \nhorribly and user-visibly broken by this proposal. AFAICS, all the common \nuse cases today will still work well with this proposal.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160560","messageId":"201102070022.51403.johan@herland.net","threadId":"26377","inReplyTo":"vpqaai8oqkc.fsf@bauges.imag.fr","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-06T23:22:51Z","receivedAt":"2011-02-06T23:22:51Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"(resend without HTML part; I apologize for the inconvenience)\n\nOn Sunday 06 February 2011, Matthieu Moy wrote:\n> Johan Herland writes:\n> > I don't see how the separate namespaces cause problems here. Also, I\n> > don't know what you're proposing instead, or indeed what other\n> > organization of tags would lead to less confusion.\n> \n> I'm not against the idea, but one drawback of the separate namespace\n> is that it introduces complexity for the user. In the common case,\n> where the user may fetch the same tag from various sources, there\n> will still be several refs (probably listed by \"git tag\" ?), and this\n> may confuse the user.\n\nIf the user is confused by putting remote tags in separate namespaces, then \nthe user is likely also confused by the current practice of putting remote \n_branches_ in separate namespaces. My point is that by strictly delineating \nthe boundaries between what is local and what belongs to a given remote, I \nhope we could help some newbies past the local vs. remote confusion that \noften manifests itself when migrating from a centralized VCS to a DVCS.\n\n> Another question is what happens when you push. With branches,\n> fetching XXX fetches in origin/XXX, but pushing YYY does push to YYY.\n> This asymetry between push and pull works well because most of the\n> time, if we have a origin/XXX branch, we also have XXX (with\n> origin/XXX as upstream).\n\nI look at it differently: \"fetch\" is for information discovery (i.e. \"I want \nto know what's happened on the remote\"), while pull/push is about making \nreal changes to local/remote branches.\n\n> For tags, it's clearly different. If I have origin/v1.7.4, I don't see\n> much reason to have _also_ v1.7.4 as a local tag. And if I have only\n> origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from\n> it will get origin/origin/v1.7.4, and so on.\n\nWrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in the \norigin remote, so there's no point in trying to push it back. On the other \nhand, if you have v1.7.4 locally (but not origin/v1.7.4), you should \n(assuming this is intended to be a public tag) consider pushing it to the \n\"origin\" remote, thus causing origin/v1.7.4 to appear in your repo.\n\n> So, my feeling is that the \"separate namespace\" should not be\n> automatic.\n> \n> For example, today, git.git repo contains tags like v1.7.4 and others\n> like gitgui-0.13.0, which is clearly a handmade namespace, where a\n> real namespace would be better. That would make a lot of sence to me\n> if Junio had something like\n> \n> [remote \"git-gui\"]\n> \turl = ...\n> \tfetch = +refs/heads/*:refs/remotes/git-gui/*\n> \tfetch = +refs/tags/*:refs/tags/remotes/git-gui/*\n> \n> or whatever other syntax, so that git-gui's tags be automatically\n> fetched into the right namespace (with no warning in case of\n> duplicate).\n> \n> But OTOH, I don't want to have several namespaces in my git repo even\n> if I configure several remotes to fetch from. In this case, duplicate\n> tags are just redundancy if they point to the same object, and a real\n> conflict I want to know about immediately otherwise.\n\nAs Nicolas mentioned elsewhere in the thread, having separate tag namespaces \ndoes not prevent us from also warning about ambiguous tag names on fetch. \nWith separate namespaces, you could probably implement such a warning more \neasily as a hook, instead of hacking the fetch code directly.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160562","messageId":"vpqtyggk9i2.fsf@bauges.imag.fr","threadId":"26377","inReplyTo":"201102070022.51403.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-06T23:51:01Z","receivedAt":"2011-02-06T23:51:01Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johan Herland writes:\n\n>> For tags, it's clearly different. If I have origin/v1.7.4, I don't see\n>> much reason to have _also_ v1.7.4 as a local tag. And if I have only\n>> origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from\n>> it will get origin/origin/v1.7.4, and so on.\n>\n> Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in the \n> origin remote, so there's no point in trying to push it back. On the other \n> hand, if you have v1.7.4 locally (but not origin/v1.7.4), you should \n> (assuming this is intended to be a public tag) consider pushing it to the \n> \"origin\" remote, thus causing origin/v1.7.4 to appear in your repo.\n\n(I made a bad choice by repeating \"origin\" several times)\n\nWhat happens if I pull from \"remoteA\" and then push to \"remoteB\"?\n\nWith branches, I'd create a local \"master\" from remoteA/master, and\nthen push my local \"master\" as \"master\" on remoteB. People looking at\nmy repository remoteB won't notice where it's comming from because it\nhad to be local for me at some point.\n\nWith tags, we probably don't want to force people to explicitely\ncreate local tags to be able to push them.\n\nTake the example of the interim maintainer cited somewhere else in\nthis thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4\ntag, and on my side, I do not want to end up having\nshawn/junio/v1.7.4, especially if this means that people fetching from\nme would end up with a me/shawn/junio/v1.7.4 ...\n\n> As Nicolas mentioned elsewhere in the thread, having separate tag namespaces \n> does not prevent us from also warning about ambiguous tag names on\n> fetch. \n\nIt does not \"prevent\", but I think it makes it a mis-feature. Distinct\nnamespaces (as opposed to warning/errors on duplicate at fetch time)\nare useful when the same short name can refer to several things (like\nv1.7.4 Vs gitgui-v1.7.4 (which doesn't exist yet), and then it's not\na problem to have twice the same short name.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160564","messageId":"AANLkTi=A-rh+wfg7O4KryydxVuorM8nkuGYmpbgVfVJp@mail.gmail.com","threadId":"26377","inReplyTo":"201102062312.51655.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-02-07T00:07:00Z","receivedAt":"2011-02-07T00:07:00Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Feb 06, 2011 at 11:12:51PM +0100, Johan Herland wrote:\n>\n> Yes, technically git 1.7.4 is a myth. However, by convention, we all agree\n> what \"v1.7.4\" points to, and nobody seriously believe they can get away with\n> pointing \"v1.7.4\" somewhere else.\n\nThere are two sorts of tags:\n- local tags, which are never intended to be shared with others but used\n by users to mark some points in the working repository.\n- global tags, which are just _social_convention_ about what the current\n project considers as official versions. Without social convention, they\n make no sense.\n\n> The core of this discussion is where we want to place Git in the space\n> between \"technically correct\" and \"socially conventional\", where the former\n> means owning up to the fact that each repo really is its own namespace, and\n> there's no way around that in a proper DVCS, and the latter means building\n> social convention into our tools, thereby making it harder to deal with the\n> few unconventional cases (like my two semi-related repos case).\n\nTags like words are social convention, which are used for communication\nbetween people participated in a project. But accordingly to you, it\nseems somehow \"technically correct\" to invent their own words in Humpty\nDumpty's ways:\n\n'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it\nmeans just what I choose it to mean — neither more nor less.'\n\nI am afraid you got the wrong idea about \"proper DVCS\", because DVCS\ndoes not imply that there is no social convention. It just means that\nthere is no single authority that dictates everything. Like with words,\nthere is no single authority that assigns meaning to new words, but\nthat does not mean that you cannot just say \"When I use a word... \"\nif you want to be understood by others.\n\n>\n> AFAICS, my proposal does not harm the common case (unambiguous tags are\n> still interpreted unambiguously, even if they may exist in multiple\n> namespaces), while it _does_ help the uncommon case (by allowing ambiguous\n> tags to co-exist in the same repo).\n\nIt hurts the common case in a few ways:\n1. It breaks existing user scripts\n2. It complicates things for users (as Matthieu wrote above).\n3. git fetch cannot report a tag clash if it happens\n\n>\n> Granted, if we leave all tags in a single namespace, I can still work around\n> this by manually futzing with the configured refspecs to create ad hoc\n> namespaces. But I _really_ hate it when I'm forced to hack around the tool,\n> because the tool thinks it \"knows better\".\n\nI believe that the right interface when the common case is simple, but\nan uncommon case is still possible to handle. I don't think that\ncurrently git meets this criterion, but making tag namespaces based on\nthe remote name strikes me as a really bad idea. Tags are attributes of\na project and not particular remote.\n\n>\n> > But, IMHO, it is a myth that having different\n> > namespaces solves the problem, because in _most_ cases, you really want\n> > to have a single namespace _semantically_, so you can communicate with\n> > other people using this tag name.\n>\n> My proposal tries very hard to present a single namespace _semantically_ to\n> the user in the common case (when tags are unambiguous). I'd even go as far\n> as proposing that \"git tag -l\" should by default list only a single\n> shortened tag name in the cases where there are multiple unambiguous\n> alternatives.\n\nIMHO, it is very confusing, especially for people whose script was\nsuddenly broken by those namespaces.\n\n>\n> Alternatively, I'd suggest a compromise (already mentioned elsewhere in this\n> thread) where we add a config variable tags.preferredRemote (defaults to\n> \"origin\") which allows you to directly select which namespace you consider\n> official. You could even implement this as physically copying\n> refs/remotes/${tag.preferredRemote}/tags/* into refs/tags/*.\n\nIt seems you do not understand the problem that I am trying to say all\nway along: there is more than one repo from which I fetch tags, and\nbecause they are belong to the same project, they should be in the same\nnamespace.\n\nSo, IMHO, the proper solution should be ability to specify the desired\nnamespace for any remote repository, like this:\n\nremote..tagNameSpace = foo\n\nSo, those who want to have many namespaces should be able to that\neasily, but forcing multiple namespaces on those who have a single\nnamespace semantically is simple wrong. Not to mention that it breaks\nexisting scripts for no good reason.\n\n>\n> > > In that case it would be wrong of gitk to display \"v1.0\". Instead it\n> > > should_ display a longer, unambiguous name, e.g. \"origin/v1.0\".\n> >\n> > But it is still ambiguous because my \"origin\" may be different from\n> > yours origin. It is only unambiguous when it look at it _locally_ but\n> > that makes it completely useless for communication with other people.\n> > One project should have only one version with the same tag regardless\n> > where it came from.\n>\n> Again, you are setting \"technical correctness\" up against \"social\n> convention\". Technically, _any_ ref name whatsoever is repo-specific and\n> \"completely useless for communication with other people\". The only thing we\n> can communicate unambiguously is SHA-1 object names. However, social\n> conventions compel us to name our refs unambiguously and to use common sense\n> when communicating, so that - in practice - everybody in the project knows\n> exactly what is meant by \"v1.0\".\n\nPublic tags are purely social convention. If there is no convention,\nthey are completely meaningless, and we can use only SHA-1. Thus\nspeaking about technical correctness of tags makes no sense.\n\n\nDmitry\n"},{"id":"160565","messageId":"AANLkTim5jGpCYA3r8wV79C8-qjxqW7ABhJrbP-C0YjLa@mail.gmail.com","threadId":"26377","inReplyTo":"201102070022.51403.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-02-07T00:14:31Z","receivedAt":"2011-02-07T00:14:31Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Feb 07, 2011 at 12:22:51AM +0100, Johan Herland wrote:\n>\n> As Nicolas mentioned elsewhere in the thread, having separate tag namespaces\n> does not prevent us from also warning about ambiguous tag names on fetch.\n> With separate namespaces, you could probably implement such a warning more\n> easily as a hook, instead of hacking the fetch code directly.\n\nSince when we started to handle the common case by forcing each user to\nwrite some hook (BTW, which one?), while having an uncommon case as the\ndefault? It makes no sense. And Nicolas suggested something different --\nalways warn on fetch, which means there will be warnings in your case\nwhere you have two projects in one repo.\n\nDmitry\n"},{"id":"160573","messageId":"alpine.LFD.2.00.1102062235550.14920@xanadu.home","threadId":"26377","inReplyTo":"201102070429.05033.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-07T03:47:08Z","receivedAt":"2011-02-07T03:47:08Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 7 Feb 2011, Johan Herland wrote:\n\n> In practice, this discussion boils down to whether we should use\n> \n> remote.origin.fetch = refs/tags/*:refs/remotes/origin/tags/*\n> or\n> remote.origin.fetch = refs/tags/*:refs/tags/*\n> \n> as the default refspec for tags. \n\nIt clearly should be (and should have been from the start) the former \none.\n\n> AFAICS, we both agree that whichever \n> refspec is chosen by default, it should be possible for the user to (fairly \n> easily) override, and use the other refspec instead.\n\nIndeed.\n\nAnd as you propose, the _usage_ of tags should largely be unchanged as \nin most cases there won't be any ambiguity, and therefore using \"git log \nv1.7.0\" will just work even if the v1.7.0 tag is actually \nrefs/remotes/origin/tags/v1.7.0.\n\nSo I hardly see what it is that people are unhappy about in this \nproposal.\n\n\nNicolas\n"},{"id":"160574","messageId":"201102070451.37370.johan@herland.net","threadId":"26377","inReplyTo":"vpqtyggk9i2.fsf@bauges.imag.fr","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-07T03:51:37Z","receivedAt":"2011-02-07T03:51:37Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 07 February 2011, Matthieu Moy wrote:\n> Johan Herland writes:\n> >> For tags, it's clearly different. If I have origin/v1.7.4, I don't see\n> >> much reason to have _also_ v1.7.4 as a local tag. And if I have only\n> >> origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from\n> >> it will get origin/origin/v1.7.4, and so on.\n> > \n> > Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in\n> > the origin remote, so there's no point in trying to push it back. On\n> > the other hand, if you have v1.7.4 locally (but not origin/v1.7.4),\n> > you should (assuming this is intended to be a public tag) consider\n> > pushing it to the \"origin\" remote, thus causing origin/v1.7.4 to\n> > appear in your repo.\n> \n> (I made a bad choice by repeating \"origin\" several times)\n> \n> What happens if I pull from \"remoteA\" and then push to \"remoteB\"?\n\nSo, when you pull from \"remoteA\", you get \n\"refs/remotes/remoteA/tags/v1.7.4\", but since it is unambiguous, you can \nrefer to it by \"v1.7.4\" instead.\n\nWhen you push to \"remoteB\", you would say \"git push remoteB tag v1.7.4\", and \nit would resolve \"v1.7.4\" (via \"refs/remotes/remoteA/tags/v1.7.4\") into the \nappropriate SHA-1, and then push the \"v1.7.4\" tag to the remote.\n\nYou have to separate the namespace from the name itself. For instance, if I \nrun \"git push remoteB tag v1.7.4\", it resolves \"v1.7.4\" into \nrefs/tags/v1.7.4, but that doesn't mean that I end up with \n\"refs/tags/refs/tags/v1.7.4\" in the \"remoteB\" repo.\n\n> Take the example of the interim maintainer cited somewhere else in\n> this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4\n> tag, and on my side, I do not want to end up having\n> shawn/junio/v1.7.4, especially if this means that people fetching from\n> me would end up with a me/shawn/junio/v1.7.4 ...\n\nYou won't end up with \"shawn/junio/v1.7.4\". When Shawn fetches from Junio, \nwhat he actually gets is \"refs/remotes/junio/tags/v1.7.4\" (\"junio/v1.7.4\" is \na shorthand; \"v1.7.4\" is an even better shorthand).\n\nNext, you should never pull from Shawn's work repo, but rather from the repo \nhe has published. In that repo he will typically have pushed the \"v1.7.4\" \ntag (as described above). When you pull from Shawn's public repo, you will \nget the \"v1.7.4\" tag at \"refs/remotes/shawn/tags/v1.7.4\" (but \"v1.7.4\" is an \nunambigious shorthand).\n\nEven if you _were_ to pull directly from Shawn's work repo, you would not \nget the \"shawn/junio/v1.7.4\" mess you fear, simply because when you fetch \nfrom a repo, the refs inside that repo's \"refs/remotes\" are not fetched.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160576","messageId":"20110207051123.GA4748@sigill.intra.peff.net","threadId":"26377","inReplyTo":"201102070451.37370.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-07T05:11:23Z","receivedAt":"2011-02-07T05:11:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 07, 2011 at 04:51:37AM +0100, Johan Herland wrote:\n\n> > Take the example of the interim maintainer cited somewhere else in\n> > this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4\n> > tag, and on my side, I do not want to end up having\n> > shawn/junio/v1.7.4, especially if this means that people fetching from\n> > me would end up with a me/shawn/junio/v1.7.4 ...\n> \n> You won't end up with \"shawn/junio/v1.7.4\". When Shawn fetches from Junio, \n> what he actually gets is \"refs/remotes/junio/tags/v1.7.4\" (\"junio/v1.7.4\" is \n> a shorthand; \"v1.7.4\" is an even better shorthand).\n\nBut keep in mind that this proposal will have to live alongside repos\nthat are using older versions of git. So Shawn might very well have\nrefs/tags/v1.7.4 from Junio if he is using (or has ever used) pre-1.8.0\ngit.\n\nNo, that won't give you me/shawn/junio/v1.7.4, but it does mean we have\nto gracefully handle the case of ambiguous duplicate tags (that happen\nto point to the same thing).\n\nWhich I think you are implying here:\n\n> Next, you should never pull from Shawn's work repo, but rather from the repo \n> he has published. In that repo he will typically have pushed the \"v1.7.4\" \n> tag (as described above). When you pull from Shawn's public repo, you will \n> get the \"v1.7.4\" tag at \"refs/remotes/shawn/tags/v1.7.4\" (but \"v1.7.4\" is an \n> unambigious shorthand).\n\nBut I wanted to point it out explicitly.\n\n-Peff\n"},{"id":"160577","messageId":"20110207051834.GB4748@sigill.intra.peff.net","threadId":"26377","inReplyTo":"alpine.LFD.2.00.1102051449420.12104@xanadu.home","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-07T05:18:34Z","receivedAt":"2011-02-07T05:18:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 05, 2011 at 02:55:06PM -0500, Nicolas Pitre wrote:\n\n> > The latter seems like a regression for the common case of fetching from\n> > two upstreams. E.g., I usually pull from Junio, getting\n> > remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I\n> > pull from him, getting remotes/spearce/v1.7.0, which he previously\n> > fetched from Junio. Under the current code, I can still do \"git show\n> > v1.7.0\"; under the scheme described above I now have to say\n> > \"origin/v1.7.0\" to disambiguate.\n> \n> Let's suppose that both tags are identical, as in your scenario above \n> they would be, then there is no need to call for any ambiguity in that \n> case.\n\nAgreed, but...\n\n> > The real issue, I think, is that we are claiming ambiguity even though\n> > those tags almost certainly point to the same sha1. When handling\n> > ambiguous tags, should we perhaps check to see if all of the ambiguities\n> > point to the same sha1, and in that case, just pick one at random?\n> \n> If they're identical then there is no randomness. If they refer to \n> different tag objects, even if those tag objects do refer to the same \n> commit object, then I'd say there is an ambiguity only if the tag object \n> content matters i.e. when displaying the tag content.\n\nMy gut feeling is that they should point to the same tag object, for the\nsake of simplicity (if you are re-tagging a commit under the same name,\nwouldn't I want to know?) and efficiency (we can detect non-ambiguity\njust by looking at the sha1 values without opening objects).\n\nBut more importantly, don't we sometimes care where the ref came from?\nIf I say \"git push remote v1.7.4\" we do some automagic on the\ndestination side of the refspec based on the fact that the source ref\nwas found in the refs/tags hierarchy. In the case we're talking about,\nall of the ambiguous refs would presumably also be coming from\nrefs/remotes/*/tags/, so they would be functionally equivalent. But I\nwanted to point it out because:\n\n 1. It is an additional equivalent requirement for two refs to not be\n ambiguous. They must have the same sha1, _and_ they must have the\n same \"type\".\n\n 2. I couldn't think of any other cases where the actual refname might\n matter and this would break. But I wanted to bring it up explicitly\n in case somebody else can think of one.\n\n-Peff\n"},{"id":"160585","messageId":"vpq7hdcjpw3.fsf@bauges.imag.fr","threadId":"26377","inReplyTo":"201102070451.37370.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-07T06:54:36Z","receivedAt":"2011-02-07T06:54:36Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johan Herland writes:\n\n> When you push to \"remoteB\", you would say \"git push remoteB tag v1.7.4\", and \n> it would resolve \"v1.7.4\" (via \"refs/remotes/remoteA/tags/v1.7.4\") into the \n> appropriate SHA-1, and then push the \"v1.7.4\" tag to the remote.\n\nThat means I can fetch git-gui/v1.0, gitk/v1.1 and git/v1.7, my\nsubproject tags are well sorted in my local repository, but if they\ndon't have the same shortname, they're not \"ambiguous\", and the\nnamespace will be completely flattened when I push (i.e. I'll push\nv1.0, v1.1 and v1.7, and people accessing my repository will not be\nable to say whether they refer to gitk, git-gui or git versions).\n\nThis defeats the point in having proper namespaces, and we'll still\nsee handmade namespaces like we already have now for git-gui tags in\ngit.git.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160589","messageId":"201102070958.11551.johan@herland.net","threadId":"26377","inReplyTo":"20110207051123.GA4748@sigill.intra.peff.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-07T08:58:11Z","receivedAt":"2011-02-07T08:58:11Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 07 February 2011, Jeff King wrote:\n> On Mon, Feb 07, 2011 at 04:51:37AM +0100, Johan Herland wrote:\n> > > Take the example of the interim maintainer cited somewhere else in\n> > > this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4\n> > > tag, and on my side, I do not want to end up having\n> > > shawn/junio/v1.7.4, especially if this means that people fetching\n> > > from me would end up with a me/shawn/junio/v1.7.4 ...\n> > \n> > You won't end up with \"shawn/junio/v1.7.4\". When Shawn fetches from\n> > Junio, what he actually gets is \"refs/remotes/junio/tags/v1.7.4\"\n> > (\"junio/v1.7.4\" is a shorthand; \"v1.7.4\" is an even better shorthand).\n> \n> But keep in mind that this proposal will have to live alongside repos\n> that are using older versions of git. So Shawn might very well have\n> refs/tags/v1.7.4 from Junio if he is using (or has ever used) pre-1.8.0\n> git.\n\nYes, but since they point to the same object, there's no ambiguity.\n\nI'm also starting to wonder whether we should, in existing repos with \nexisting remotes, keep using the old-style refspecs by default, thereby \nmaking new-style refspecs the default only for _new_ repos. It seems mixing \nthe two styles in one repo would cause confusion. Another alternative would \nbe to transform old-style remotes into new-style remotes, but I believe that \nwas shot down elsewhere in this thread.\n\n> No, that won't give you me/shawn/junio/v1.7.4, but it does mean we have\n> to gracefully handle the case of ambiguous duplicate tags (that happen\n> to point to the same thing).\n\nWhoa, we use the \"ambiguous\" term differently here. In this whole thread I \nhave used \"ambiguous\" exclusively about when the same (shorthand) tag name \npoint to _different_ things. As long as they point to the same thing, there \nis no ambiguity, IMHO.\n\n> Which I think you are implying here:\n> > Next, you should never pull from Shawn's work repo, but rather from the\n> > repo he has published. In that repo he will typically have pushed the\n> > \"v1.7.4\" tag (as described above). When you pull from Shawn's public\n> > repo, you will get the \"v1.7.4\" tag at\n> > \"refs/remotes/shawn/tags/v1.7.4\" (but \"v1.7.4\" is an unambigious\n> > shorthand).\n> \n> But I wanted to point it out explicitly.\n\nYes, over its lifetime a tag name (\"v1.7.4\") might appear in several \nnamespaces (refs/tags, refs/remotes/*/tags), but it's always identifiable \nwith the shorthand \"v1.7.4\" name (assuming no other \"v1.7.4\" name point to a \ndifferent object).\n\nThis is the same technique we use when talking about branch names: On this \nmailing list, nobody is confused when I refer to 'maint', 'master', 'next' \nand 'pu'. Still, in our own work repos (at least in mine), these branches \nare actually called \"refs/remotes/origin/\" (commonly referred to by \ntheir shorthands \"origin/\"). Here we are, juggling the same kind of \nnamespaces that I propose for tags, and it seems to work well without \ncausing much confusion.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160590","messageId":"AANLkTiksUqVnWeZOm-9XN3BbfVcjc6fWdwPcPJ-PLb88@mail.gmail.com","threadId":"26377","inReplyTo":"201102070958.11551.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-07T09:01:06Z","receivedAt":"2011-02-07T09:01:06Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Feb 7, 2011 at 09:58, Johan Herland wrote:\n> This is the same technique we use when talking about branch names: On this\n> mailing list, nobody is confused when I refer to 'maint', 'master', 'next'\n> and 'pu'. Still, in our own work repos (at least in mine), these branches\n> are actually called \"refs/remotes/origin/\" (commonly referred to by\n> their shorthands \"origin/\"). Here we are, juggling the same kind of\n> namespaces that I propose for tags, and it seems to work well without\n> causing much confusion.\n\nWith the difference that you can't refer to \"maint\" as just \"maint\"\nunless you've created \"refs/heads/maint\" iff it is unambiguous.\n\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"160595","messageId":"201102071106.17269.johan@herland.net","threadId":"26377","inReplyTo":"AANLkTiksUqVnWeZOm-9XN3BbfVcjc6fWdwPcPJ-PLb88@mail.gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-07T10:06:16Z","receivedAt":"2011-02-07T10:06:16Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 07 February 2011, Sverre Rabbelier wrote:\n> On Mon, Feb 7, 2011 at 09:58, Johan Herland wrote:\n> > This is the same technique we use when talking about branch names:\n> > On this mailing list, nobody is confused when I refer to 'maint',\n> > 'master', 'next' and 'pu'. Still, in our own work repos (at least\n> > in mine), these branches are actually called\n> > \"refs/remotes/origin/\" (commonly referred to by their\n> > shorthands \"origin/\"). Here we are, juggling the same kind of\n> > namespaces that I propose for tags, and it seems to work well\n> > without causing much confusion.\n>\n> With the difference that you can't refer to \"maint\" as just \"maint\"\n> unless you've created \"refs/heads/maint\" iff it is unambiguous.\n\nExcept that with 'git checkout', you can:\n\n$ git clone git://git.kernel.org/pub/scm/git/git.git\n$ cd git/\n$ git checkout maint\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160596","messageId":"AANLkTinmOiiizW6eDkAffpWXP+Xztyv1YJfHp2nfFUZ=@mail.gmail.com","threadId":"26377","inReplyTo":"201102071106.17269.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-07T10:22:26Z","receivedAt":"2011-02-07T10:22:26Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 7, 2011 at 5:06 PM, Johan Herland wrote:\n> On Monday 07 February 2011, Sverre Rabbelier wrote:\n>> On Mon, Feb 7, 2011 at 09:58, Johan Herland wrote:\n>> > This is the same technique we use when talking about branch names:\n>> > On this mailing list, nobody is confused when I refer to 'maint',\n>> > 'master', 'next' and 'pu'. Still, in our own work repos (at least\n>> > in mine), these branches are actually called\n>> > \"refs/remotes/origin/\" (commonly referred to by their\n>> > shorthands \"origin/\"). Here we are, juggling the same kind of\n>> > namespaces that I propose for tags, and it seems to work well\n>> > without causing much confusion.\n>>\n>> With the difference that you can't refer to \"maint\" as just \"maint\"\n>> unless you've created \"refs/heads/maint\" iff it is unambiguous.\n>\n> Except that with 'git checkout', you can:\n>\n> $ git clone git://git.kernel.org/pub/scm/git/git.git\n> $ cd git/\n> $ git checkout maint\n\nThat's some checkout magic kicking in. I cloned and there was only\nrefs/heads/master. After checkout, refs/heads/maint appeared.\n\n$ git clone git://git.kernel.org/pub/scm/git/git.git git2\n$ cd git2\n$ git rev-parse maint\nmaint\nfatal: ambiguous argument 'maint': unknown revision or path not in the\nworking tree.\nUse '--' to separate paths from revisions\n$ git rev-parse origin/maint\n597a63054241c122515c93cbce45bc44eb231f18\n$ git co maint\nBranch maint set up to track remote branch maint from origin.\nSwitched to a new branch 'maint'\n$ git rev-parse maint\n597a63054241c122515c93cbce45bc44eb231f18\n-- \nDuy\n"},{"id":"160609","messageId":"alpine.LFD.2.00.1102070936530.14920@xanadu.home","threadId":"26377","inReplyTo":"20110207051834.GB4748@sigill.intra.peff.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-07T14:53:29Z","receivedAt":"2011-02-07T14:53:29Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 7 Feb 2011, Jeff King wrote:\n\n> On Sat, Feb 05, 2011 at 02:55:06PM -0500, Nicolas Pitre wrote:\n> \n> > > The latter seems like a regression for the common case of fetching from\n> > > two upstreams. E.g., I usually pull from Junio, getting\n> > > remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I\n> > > pull from him, getting remotes/spearce/v1.7.0, which he previously\n> > > fetched from Junio. Under the current code, I can still do \"git show\n> > > v1.7.0\"; under the scheme described above I now have to say\n> > > \"origin/v1.7.0\" to disambiguate.\n> > \n> > Let's suppose that both tags are identical, as in your scenario above \n> > they would be, then there is no need to call for any ambiguity in that \n> > case.\n> \n> Agreed, but...\n> \n> > > The real issue, I think, is that we are claiming ambiguity even though\n> > > those tags almost certainly point to the same sha1. When handling\n> > > ambiguous tags, should we perhaps check to see if all of the ambiguities\n> > > point to the same sha1, and in that case, just pick one at random?\n> > \n> > If they're identical then there is no randomness. If they refer to \n> > different tag objects, even if those tag objects do refer to the same \n> > commit object, then I'd say there is an ambiguity only if the tag object \n> > content matters i.e. when displaying the tag content.\n> \n> My gut feeling is that they should point to the same tag object, for the\n> sake of simplicity (if you are re-tagging a commit under the same name,\n> wouldn't I want to know?) and efficiency (we can detect non-ambiguity\n> just by looking at the sha1 values without opening objects).\n\nAgreed. Same tag name referring to same commit but with different tag \nobjects is a bit silly and trying to make that case non ambiguous is \nprobably going to cause more confusion anyway. If the tag object is \ndifferent then this is for most purposes a different tag.\n\n> But more importantly, don't we sometimes care where the ref came from?\n\nNot at the moment. Certainly not with the current flat namespace used \nfor tags.\n\n> If I say \"git push remote v1.7.4\" we do some automagic on the\n> destination side of the refspec based on the fact that the source ref\n> was found in the refs/tags hierarchy. In the case we're talking about,\n> all of the ambiguous refs would presumably also be coming from\n> refs/remotes/*/tags/, so they would be functionally equivalent. But I\n> wanted to point it out because:\n> \n> 1. It is an additional equivalent requirement for two refs to not be\n> ambiguous. They must have the same sha1, _and_ they must have the\n> same \"type\".\n\nHow can this matter? The same automagic on the destination ref may \nstill take place. Semantically you want to push v1.7.4 so nothing has \nto change there, irrespective of the namespace the v1.7.4 tag comes \nfrom. This doesn't matter today, so why would this particular case need \nto change?\n\n\nNicolas\n"},{"id":"160612","messageId":"4D501983.5060508@xiplink.com","threadId":"26377","inReplyTo":"7vvd0xvsjc.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-02-07T16:10:43Z","receivedAt":"2011-02-07T16:10:43Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-02-06 03:04 PM, Junio C Hamano wrote:\n> Nicolas Pitre writes:\n> \n>>> The latter seems like a regression for the common case of fetching from\n>>> two upstreams. E.g., I usually pull from Junio, getting\n>>> remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I\n>>> pull from him, getting remotes/spearce/v1.7.0, which he previously\n>>> fetched from Junio. Under the current code, I can still do \"git show\n>>> v1.7.0\"; under the scheme described above I now have to say\n>>> \"origin/v1.7.0\" to disambiguate.\n>>\n>> Let's suppose that both tags are identical, as in your scenario above \n>> they would be, then there is no need to call for any ambiguity in that \n>> case.\n> \n> I agree that we do not want refs/remotes/tags/*/that-tag-people-agree-on\n> in that case. We want to store a single copy and find it there, and that\n> single copy has traditionally been found in refs/tags hierarchy.\n> \n> I think the real issue is not necessarily that the location is shared with\n> local tag namespace, but is the lack of a convenient way (or just BCP) to\n> segregate what are local and what are official when transferring tags out\n> of your repository. That is what discourages people from using tags for\n> their personal and ephemeral use, marking some points in their own work\n> with personal tags that are never intended to be published.\n\nThat may be an issue, but I don't think it's the issue in this thread.\nRecall what Nicolas said:\n\n\tThe extraordinary misfeature of the tag namespace at the\n\tmoment comes from the fact that whenever you add a remote\n\trepo to fetch, and do fetch it, then your flat tag\n\tnamespace gets polluted with all the tags the remote might\n\thave. If you decide to delete some of those remote branches,\n\tthe tags that came with it are still there and indistinguishable\n\tfrom other tags making it a real pain to sort out.\n\nThose tags can all be properly \"official\" and still the problem exists.\n\nIn the \"interim maintainer\" case, I suggest it's not really a question of\nprivate-vs-official tags. Folks who clone directly from the maintainer\nshould understand that some tags are works-in-progress. As the maintainer\nrole gets passed from person to person (and repo to repo), it seems more\nuseful to be able to distinguish work-in-progress tag vX.Y.Z as coming from\nmaintainer A or B, i.e. tags A/vX.Y.Z and B/vX.Y.Z. If the tags point to the\nsame commit then just \"vX.Y.Z\" resolves fine. But if the two maintainers\nhave different ideas of what vX.Y.Z should be, then the fully-qualified names\nhelp to identify the differences.\n\nTags don't become \"official\" until they're published according to the\nproject's process. For us git users, that means the tag appears in\ngit.kernel.org/pub/scm/git/git.git. A tag that appears somewhere else can\nhave all sorts of meanings, but I don't think \"official\" could be one of them.\n\n\t\tM.\n"},{"id":"160619","messageId":"20110207190551.GA25413@pcpool00.mathematik.uni-freiburg.de","threadId":"26377","inReplyTo":"AANLkTi=A-rh+wfg7O4KryydxVuorM8nkuGYmpbgVfVJp@mail.gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Bernhard R. Link","fromEmail":"brl+ccmadness@pcpool00.mathematik.uni-freiburg.de","sentAt":"2011-02-07T19:05:51Z","receivedAt":"2011-02-07T19:05:51Z","isPatch":false,"sender":{"key":"brl+ccmadness@pcpool00.mathematik.uni-freiburg.de","avatar":null},"body":"* Dmitry Potapov [110207 01:07]:\n> There are two sorts of tags:\n> - local tags, which are never intended to be shared with others but used\n> by users to mark some points in the working repository.\n> - global tags, which are just _social_convention_ about what the current\n> project considers as official versions. Without social convention, they\n> make no sense.\n>[...]\n> It seems you do not understand the problem that I am trying to say all\n> way along: there is more than one repo from which I fetch tags, and\n> because they are belong to the same project, they should be in the same\n> namespace.\n\nSo there are those \"local tags\", which are not to be shared with others.\nDoes that mean an user should always have two repositories, one with\nthose tags for themselves and one without those tags for each other?\n\nAnd the private one should always be the one that does the push and\nfetch (as issuing a a fetch in the public to get something from the\nprivate will also get all those tags)?\n\n> > Granted, if we leave all tags in a single namespace, I can still work around\n> > this by manually futzing with the configured refspecs to create ad hoc\n> > namespaces. But I _really_ hate it when I'm forced to hack around the tool,\n> > because the tool thinks it \"knows better\".\n>\n> I believe that the right interface when the common case is simple, but\n> an uncommon case is still possible to handle. I don't think that\n> currently git meets this criterion, but making tag namespaces based on\n> the remote name strikes me as a really bad idea. Tags are attributes of\n> a project and not particular remote.\n\nGlobal tags are. Local tags are not.\nAnd even for global tags it can be interesting to see which remote has\nthem, without having to manually look at all those remotes.\n\n> IMHO, it is very confusing, especially for people whose script was\n> suddenly broken by those namespaces.\n\nLike it was when remotes where introduced?\n\n> So, IMHO, the proper solution should be ability to specify the desired\n> namespace for any remote repository, like this:\n>\n> remote..tagNameSpace = foo\n>\n> So, those who want to have many namespaces should be able to that\n> easily, but forcing multiple namespaces on those who have a single\n> namespace semantically is simple wrong. Not to mention that it breaks\n> existing scripts for no good reason.\n\nI'd consider it more logical to have remote tags and a config to\nautomatically make local copies of remote tags. (With whatever default\npeople consider proper).\n\n\n\tBernhard R. Link\n"},{"id":"161592","messageId":"7v62svvdjo.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"4D501983.5060508@xiplink.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-07T19:40:27Z","receivedAt":"2011-02-07T19:40:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> Tags don't become \"official\" until they're published according to the\n> project's process. For us git users, that means the tag appears in\n> git.kernel.org/pub/scm/git/git.git. A tag that appears somewhere else can\n> have all sorts of meanings, but I don't think \"official\" could be one of them.\n\nI think you are essentially saying the same thing.\n\nThink of hiding the unofficial tags to refs/private-tags by \"interim\nmaintainer\" (or public at large for that matter); they won't be published\nautomatically, unless the publisher decides to publish \"according to the\nproject's process.\"\n\nAs I said in my message, it feels awkward to use refs/private-tags for\ntags everybody uses for his or her own purpose, so by swapping the roles\nof namespaces around, we would be able to use refs/tags for private ones,\nand refs/remotes/origin/tags for the ones that came from upstream. But\nthen if you fetch/pull from a third party (including the \"interim\nmaintainer\"), it feels wasteful to get full set of tags that you have in\nthe origin namespace anyway replicated in refs/remotes/interim/tags.\n\nAnd that is what bothers me---not the waste itself, but I have this\nnagging feeling that the wasteful duplication is an indication of\nsomething else designed wrong.\n"},{"id":"160623","messageId":"20110207201912.GB13461@sigill.intra.peff.net","threadId":"26377","inReplyTo":"201102070958.11551.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-07T20:19:13Z","receivedAt":"2011-02-07T20:19:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote:\n\n> > No, that won't give you me/shawn/junio/v1.7.4, but it does mean we have\n> > to gracefully handle the case of ambiguous duplicate tags (that happen\n> > to point to the same thing).\n> \n> Whoa, we use the \"ambiguous\" term differently here. In this whole thread I \n> have used \"ambiguous\" exclusively about when the same (shorthand) tag name \n> point to _different_ things. As long as they point to the same thing, there \n> is no ambiguity, IMHO.\n\nSorry, I should have been more clear. I meant \"ambiguous by the current\ncode's definition\", meaning \"we would still need to use your new\nambiguity definition to resolve this situation\".\n\nIOW, I think we are on the same page.\n\n> This is the same technique we use when talking about branch names: On this \n> mailing list, nobody is confused when I refer to 'maint', 'master', 'next' \n> and 'pu'. Still, in our own work repos (at least in mine), these branches \n> are actually called \"refs/remotes/origin/\" (commonly referred to by \n> their shorthands \"origin/\"). Here we are, juggling the same kind of \n> namespaces that I propose for tags, and it seems to work well without \n> causing much confusion.\n\nJust playing devil's advocate for a moment: isn't this namespace\ndistinction one of the more confusing things in git for new users? That\nis, I have seen new-ish git users say \"OK, so I cloned from upstream.\nHow come I can't say \"git log maint\" now?\" Or it used to be \"how come I\ncan't \"git checkout maint\" now?\" The latter is now handled by some very\nspecific magic in \"git checkout\", but in general ref lookup does not\nautomagically look in remotes namespaces, and it has caused some\nconfusion.\n\nSo here we are introducing more distinction between project-wide names\nand per-remote names. I absolutely think it's the right thing to do from\na \"keep it simple, orthogonal, and distributed\" perspective. But we also\nneed to recognize we are making some common use cases more confusing. In\nthe case of remote-tracking branches, we ended up adding some porcelain\nfeatures to make common actions (like checking out a local branch from a\nremote) more seamless. But there is still some confusion among new\nusers.\n\nI'm sort of rambling as I'm not quite sure yet what this means for the\ntags proposal, but a few questions I think are important to consider\nare:\n\n 1. Where have we succeeded and where have we failed with making\n separate-remotes / tracking branches seamless to the user (as\n opposed to something like a system where\n fetching from upstream fetches straight into your master branch\n (which has its own problems, but would be conceptually very\n simple)? Do those failures apply in this case, and if so how can we\n do better?\n\n 2. Can we apply new ideas for handling separate-remote tags to the\n branches case? Obviously one big proposal is searching in the\n per-remote tag namespace for refs. Should we be doing the same with\n heads?\n\n-Peff\n"},{"id":"160625","messageId":"20110207202551.GC13461@sigill.intra.peff.net","threadId":"26377","inReplyTo":"alpine.LFD.2.00.1102070936530.14920@xanadu.home","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-07T20:25:51Z","receivedAt":"2011-02-07T20:25:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 07, 2011 at 09:53:29AM -0500, Nicolas Pitre wrote:\n\n> > But more importantly, don't we sometimes care where the ref came from?\n> \n> Not at the moment. Certainly not with the current flat namespace used \n> for tags.\n\nI'm not sure I was clear. I didn't mean \"which remote the ref came from\"\nbut rather \"when choosing between two refs, don't we sometimes care\nabout the actual name of the ref?\". But see below.\n\n> > If I say \"git push remote v1.7.4\" we do some automagic on the\n> > destination side of the refspec based on the fact that the source ref\n> > was found in the refs/tags hierarchy. In the case we're talking about,\n> > all of the ambiguous refs would presumably also be coming from\n> > refs/remotes/*/tags/, so they would be functionally equivalent. But I\n> > wanted to point it out because:\n> > \n> > 1. It is an additional equivalent requirement for two refs to not be\n> > ambiguous. They must have the same sha1, _and_ they must have the\n> > same \"type\".\n> \n> How can this matter? The same automagic on the destination ref may \n> still take place. Semantically you want to push v1.7.4 so nothing has \n> to change there, irrespective of the namespace the v1.7.4 tag comes \n> from. This doesn't matter today, so why would this particular case need \n> to change?\n\nI guess the problem is that I'm not clear on exactly what the new lookup\n/ ambiguity rules are proposed to be. Clearly something will need to go\nin the dwim_ref level. And I think it's obvious that if \"refs/tags/foo\"\nand \"refs/remotes/*/tags/foo\" point to the same sha1, they will not be\nconsidered ambiguous.\n\nWill the same apply to refs/heads/foo versus refs/remotes/*/foo? Will it\nalso apply to refs/heads/foo versus refs/remotes/*/tags/foo? In the\nfinal case, that does matter to \"git push\" (should the destination be in\nthe head or tag namespace?). So the actual names of the ref can matter,\nand should probably be taken into account when deciding what is\nambiguous.\n\nMaybe that was obvious to everybody and it was an implicit part of the\nproposal, but it wasn't clear to me.\n\n-Peff\n"},{"id":"160626","messageId":"alpine.LFD.2.00.1102071517070.14920@xanadu.home","threadId":"26377","inReplyTo":"7v62svvdjo.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-07T20:37:38Z","receivedAt":"2011-02-07T20:37:38Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 7 Feb 2011, Junio C Hamano wrote:\n\n> As I said in my message, it feels awkward to use refs/private-tags for\n> tags everybody uses for his or her own purpose, so by swapping the roles\n> of namespaces around, we would be able to use refs/tags for private ones,\n> and refs/remotes/origin/tags for the ones that came from upstream. But\n> then if you fetch/pull from a third party (including the \"interim\n> maintainer\"), it feels wasteful to get full set of tags that you have in\n> the origin namespace anyway replicated in refs/remotes/interim/tags.\n\nWhy so? At least you get to know if that particular remote has a \nparticular tag that may also exist elsewhere. And if you decide to drop \none remote source with all its tags from your local repository, then the \nremaining one(s) still have relevant tags available.\n\n> And that is what bothers me---not the waste itself, but I have this\n> nagging feeling that the wasteful duplication is an indication of\n> something else designed wrong.\n\nWe do have \"wasteful\" duplicated references all over the place, such as \nwhen two directories (tree objects) contain the same file content (refer \nto the same blob object). But no one feels like this is wasted \nduplication as those two directories end up using the same single blob \nobject even if in the working directory you get twice the content.\n\nHere this is the same thing. You have multiple handles to the same tag \nwhich are distributed across different remote repositoryes you are \ntracking. The name on the tag may be found in many places, and even \nunder different names. But there is still only one actual tag object.\n\nIf you have 3 remotes sharing the same tag then you know that the tag \ncannot be garbage collected until all three remotes have been removed \nfrom your repository.\n\nSimply storing snapshots of the tag state per remote repository is \nsimple and allow for smarter processing on top, which is in agreement \nwith the design philosophy for the rest of Git.\n\n\nNicolas\n"},{"id":"160632","messageId":"alpine.LFD.2.00.1102071541460.14920@xanadu.home","threadId":"26377","inReplyTo":"20110207202551.GC13461@sigill.intra.peff.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-07T20:51:55Z","receivedAt":"2011-02-07T20:51:55Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 7 Feb 2011, Jeff King wrote:\n\n> I guess the problem is that I'm not clear on exactly what the new lookup\n> / ambiguity rules are proposed to be. Clearly something will need to go\n> in the dwim_ref level. And I think it's obvious that if \"refs/tags/foo\"\n> and \"refs/remotes/*/tags/foo\" point to the same sha1, they will not be\n> considered ambiguous.\n\nAgreed.\n\n> Will the same apply to refs/heads/foo versus refs/remotes/*/foo?\n\nI think it should. If both branches are pointing to the same commit \nthen the short form \"foo\" should be unambigous and the operation proceed \n(be that 'git push' or 'git log' that shouldn't matter).\n\n> Will it\n> also apply to refs/heads/foo versus refs/remotes/*/tags/foo? In the\n> final case, that does matter to \"git push\" (should the destination be in\n> the head or tag namespace?).\n\nIn such a case I'd say that head refs have precedence over tag refs, and \nwhen that occurs then warn the user. And I wouldn't make a special \ncase for 'git push' here. Whether it is push or log, the head ref would \ntake precedence, and the user warned about existence of a tag with the \nsame name. Of course using \"tag/foo\" should be unambigous again.\n\n> So the actual names of the ref can matter,\n> and should probably be taken into account when deciding what is\n> ambiguous.\n\nWhat happens today when you have refs/heads/foo and refs/tags/foo?\n\n\nNicolas\n"},{"id":"160636","messageId":"20110207205630.GA14768@sigill.intra.peff.net","threadId":"26377","inReplyTo":"alpine.LFD.2.00.1102071541460.14920@xanadu.home","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-07T20:56:30Z","receivedAt":"2011-02-07T20:56:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 07, 2011 at 03:51:55PM -0500, Nicolas Pitre wrote:\n\n> > Will it\n> > also apply to refs/heads/foo versus refs/remotes/*/tags/foo? In the\n> > final case, that does matter to \"git push\" (should the destination be in\n> > the head or tag namespace?).\n> \n> In such a case I'd say that head refs have precedence over tag refs, and \n> when that occurs then warn the user. And I wouldn't make a special \n> case for 'git push' here. Whether it is push or log, the head ref would \n> take precedence, and the user warned about existence of a tag with the \n> same name. Of course using \"tag/foo\" should be unambigous again.\n\nI am fine with that, although it is the opposite of the current dwim_ref\nbehavior (which warns on ambiguity but prefers tags). However, Junio has\nsaid that the current behavior was simply arbitrary.\n\n> > So the actual names of the ref can matter,\n> > and should probably be taken into account when deciding what is\n> > ambiguous.\n> \n> What happens today when you have refs/heads/foo and refs/tags/foo?\n\nFor dwim_ref, it prefers the tag and issues a warning. For git-push, it\ncomplains about the ambiguity and dies. For git checkout, we prefer the\nhead. For git-tag, we prefer the tag (though I think that only matters\nfor \"git tag -d\").\n\n-Peff\n"},{"id":"160667","messageId":"201102080159.02153.johan@herland.net","threadId":"26377","inReplyTo":"20110207201912.GB13461@sigill.intra.peff.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-08T00:59:01Z","receivedAt":"2011-02-08T00:59:01Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 07 February 2011, Jeff King wrote:\n> On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote:\n> > This is the same technique we use when talking about branch names: On\n> > this mailing list, nobody is confused when I refer to 'maint',\n> > 'master', 'next' and 'pu'. Still, in our own work repos (at least in\n> > mine), these branches are actually called \"refs/remotes/origin/\"\n> > (commonly referred to by their shorthands \"origin/\"). Here we\n> > are, juggling the same kind of namespaces that I propose for tags, and\n> > it seems to work well without causing much confusion.\n> \n> Just playing devil's advocate for a moment: isn't this namespace\n> distinction one of the more confusing things in git for new users? That\n> is, I have seen new-ish git users say \"OK, so I cloned from upstream.\n> How come I can't say \"git log maint\" now?\" Or it used to be \"how come I\n> can't \"git checkout maint\" now?\" The latter is now handled by some very\n> specific magic in \"git checkout\", but in general ref lookup does not\n> automagically look in remotes namespaces, and it has caused some\n> confusion.\n> \n> So here we are introducing more distinction between project-wide names\n> and per-remote names. I absolutely think it's the right thing to do from\n> a \"keep it simple, orthogonal, and distributed\" perspective. But we also\n> need to recognize we are making some common use cases more confusing. In\n> the case of remote-tracking branches, we ended up adding some porcelain\n> features to make common actions (like checking out a local branch from a\n> remote) more seamless. But there is still some confusion among new\n> users.\n> \n> I'm sort of rambling as I'm not quite sure yet what this means for the\n> tags proposal, but a few questions I think are important to consider\n> are:\n> \n> 1. Where have we succeeded and where have we failed with making\n> separate-remotes / tracking branches seamless to the user (as\n> opposed to something like a system where\n> fetching from upstream fetches straight into your master branch\n> (which has its own problems, but would be conceptually very\n> simple)? Do those failures apply in this case, and if so how can we\n> do better?\n> \n> 2. Can we apply new ideas for handling separate-remote tags to the\n> branches case? Obviously one big proposal is searching in the\n> per-remote tag namespace for refs. Should we be doing the same with\n> heads?\n\nI pretty much completely agree with your train of thought.\n\nFirst, although the separate-remotes may at first be confusing to newbies \ncoming from a centralized VCS, I don't think this is the _main_ source of \nconfusion. And, as you imply, we cannot eliminate this kind of conceptual \nconfusion in any case, without violating core DVCS principles (like Bazaar \ndoes in its \"centralized workflow\"). The best way to address this is, as you \nsay, by keeping it \"simple, orthogonal, and distributed\" (and try very hard \nto keep the common use cases minimally affected).\n\nWe should instead look at what other (and preferrable fixable) sources of \nconfusion we have in this area. Answering Git questions from colleagues at \n$dayjob, they often describe how they tried to accomplish something in Git, \nand I sometimes find myself giving a reply of the following form: \"Yes, what \nyou tried does make sense from your POV, but in this situation Git actually \ndoes this other thing instead, so instead you have to do ...\". I don't like \ngiving answers like this, because I get this nagging feeling that the \nproblem is Git's fault, and not the user's. So, to enumerate some of these \ninconsistencies (I'm sure there are more that I cannot recall, right now):\n\n- Lack of consistency in the ref namespace (refs/remotes/$remote/* vs. \nrefs/tags/*). Also not clear from the current layout where to add new types \nof refs (e.g. notes, replace). My proposal tries to address this issue.\n\n- Lack of consistency in which fetch refspecs must be listed in the \nconfiguration. (i.e. implicit vs. explicit fetch refspecs). My proposal \ntries to address this as well.\n\n- Lack of consistency in porcelain interfaces. Some of these have been fixed \nin recent Git version, but some are yet to be fixed: E.g. some find the use \nof FETCH_HEAD confusing (when does fetch update the remote refs, and when \ndoes it update FETCH_HEAD instead?). Others (myself included) wonder why \n'git push' by default updates remote branches with matching names, while \n'git pull' relies on the explicitly configured upstreams to update the local \nrefs. (FWIW, I've mitigated this last complaint insisting that all users at \n$dayjob run \"git config --global push.default tracking\" immediately after \ninstalling Git.) There are other UI inconsistencies too that escape me ATM.\n\nWhen it comes to your second question, I believe it's definitely worth \nlooking closer at whether we can exploit unambiguity across namespaces for \nall types of refs (not just tags). I expect there are some non-trivial \nissues down that road (some of these being discussed elsewhere in this \nthread), but we may still end up with something better.\n\n\nThanks for the feedback! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160669","messageId":"20110208010648.GA3132@dpotapov.dyndns.org","threadId":"26377","inReplyTo":"201102070429.05033.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-02-08T01:06:48Z","receivedAt":"2011-02-08T01:06:48Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Feb 07, 2011 at 04:29:04AM +0100, Johan Herland wrote:\n> \n> As I understand your view (I do apologize if I somehow misrepresent it), you \n> want Git to assume that the common practice of one semantic namespace is \n> followed. Furthermore, you also want to enforce that practice where \n> possible, while still improving the handling of the uncommon (but \n> theoretically inevitable) case (warning and presumably guiding the user when \n> a tag conflict occurs).\n\nYes, you are correct. I consider a single tag namespace as the common\ncase, but it should be possible to have more than one namespace for\nthose who needs that. I think our disagreement is due to the fact that\nyou believe that if someone added another remote, he or she wants\nanother namespace for tags, but I think it depends on whether you treat\ndifferent remotes as one project or different semi-related projects.\n\nThere is a fundamental difference between branches and tags is that\nbranches are often different (like each co-worker can publish each own\nmaster that he or she tested), but tags should have same tags as long as\nwe work on the same project, otherwise it will lead to confusion.\n\n> \n> > 2. It complicates things for users (as Matthieu wrote above).\n> \n> I guess this depends on your POV. Fundamentally, I do NOT want to change how \n> people refer to tags. I only want to provide them the possibility of doing \n> so when ambiguity is present.\n\nIMHO, there are two fundamentally two different use cases:\n- one project with many remotes\n- two (probably semi-related) projects in the same repo\n\nIn the first case, having two tags pointing to different commits is an\nobvious mistake that should be fixed as soon as possible. I do not think\nthat different namespaces are necessary to fix that (or at least I do\nnot see how it helps), but my main concern was that resolution of a tag\nconflict may be postponed (because they appear in different namespaces),\nbut that does not resolve the confusion and may only prolong it.\n\n> \n> > 3. git fetch cannot report a tag clash if it happens\n> \n> Yes it can: For each tag fetched from the remote, if resolving its shorthand \n> name (\"v1.7.4\") results in ambiguity (i.e. there exists a conflicting tag \n> elsewhere in this repo), then warn the user about this conflict, and explain \n> how to refer to each tag candidate using the full ref name. Also explain how \n> the user may resolve the ambiguity by creating a local tag \n> (\"refs/tags/v1.7.4\") pointing to the preferred target.\n\nIt it is possible then I do not have any serious objection here...\n\n> > So, IMHO, the proper solution should be ability to specify the desired\n> > namespace for any remote repository, like this:\n> > \n> > remote..tagNameSpace = foo\n> \n> Interesting. I'm not sure what \"foo\" means in this context. Would I use it \n> like this?:\n> \n> remote.origin.tagNameSpace = refs/tags\n\nI was not sure about the specific when I wrote this, so I just put \"foo\",\nbut it could be something like you wrote above.\n\n> \n> (to place origin's tags in refs/tags/*)\n> \n> If so, what's the difference between this option, and using this?:\n> \n> remote.origin.fetch = refs/tags/*:refs/tags/*\n\nI have not tried that, but I suspect that it will cause that all tags\nwill be fetched even if they are not belong to tracked branches, i.e.\n\"git fetch\" will work as \"git fetch -t\". But maybe I am wrong here.\n\n\nDmitry\n"},{"id":"160670","messageId":"20110208012018.GB3132@dpotapov.dyndns.org","threadId":"26377","inReplyTo":"20110207190551.GA25413@pcpool00.mathematik.uni-freiburg.de","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-02-08T01:20:18Z","receivedAt":"2011-02-08T01:20:18Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Feb 07, 2011 at 08:05:51PM +0100, Bernhard R. Link wrote:\n> \n> So there are those \"local tags\", which are not to be shared with others.\n> Does that mean an user should always have two repositories, one with\n> those tags for themselves and one without those tags for each other?\n\nWell, I believe that the best practice is that each developer has\nhis/her own private repo and there is also a \"bare\" repo to which\nis used to share results with others. In this way, local tags are\nstay only inside one's private repo.\n\nIf you need to fetch directly from someone working repository, you can\nuse \"git fetch --no-tags\", but obviously it is not an optimal solution\nif you also need to fetch global tags from it, because you will have\nto specify them explicitly.\n\n> > > Granted, if we leave all tags in a single namespace, I can still work around\n> > > this by manually futzing with the configured refspecs to create ad hoc\n> > > namespaces. But I _really_ hate it when I'm forced to hack around the tool,\n> > > because the tool thinks it \"knows better\".\n> >\n> > I believe that the right interface when the common case is simple, but\n> > an uncommon case is still possible to handle. I don't think that\n> > currently git meets this criterion, but making tag namespaces based on\n> > the remote name strikes me as a really bad idea. Tags are attributes of\n> > a project and not particular remote.\n> \n> Global tags are. Local tags are not.\n\nSure. I probably should have said that I'd consider only global tags in\nthe rest of my email, because local tags should not be normally visible\noutside of one's repo.\n\n> And even for global tags it can be interesting to see which remote has\n> them, without having to manually look at all those remotes.\n\nI am not sure why it should be interesting. I mean as long as you do\nnot have tag clashes, you should not need to know that. And if you\nreally need to know that, you can use \"git ls-remote\" to check actual\nreferences.\n\n> \n> > IMHO, it is very confusing, especially for people whose script was\n> > suddenly broken by those namespaces.\n> \n> Like it was when remotes where introduced?\n\nHow many people used git back then and how many people are using now?\nHave you forgotten what happened when the dash was removed from git\ncommands? There was endless cry about breaking git, though all what\nthose people need to do is to add one directory to their PATH to have\ngit dash commands back.\n\nSo, what may be okay for a young and immature project (used by a small\ngroup of enthusiasts) may be not okay for a tool on which many people\nrely. Most people who use git now do not read ReleaseNotes. They just\ninstall a ready package for their favorite distro and expect everything\nto work as before.\n\nSo, I think any changes should be introduced as gradual as possible.\n\n\nDmitry\n"},{"id":"160682","messageId":"201102080915.27484.johan@herland.net","threadId":"26377","inReplyTo":"20110208010648.GA3132@dpotapov.dyndns.org","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-08T08:15:27Z","receivedAt":"2011-02-08T08:15:27Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 08 February 2011, Dmitry Potapov wrote:\n> On Mon, Feb 07, 2011 at 04:29:04AM +0100, Johan Herland wrote:\n> > > So, IMHO, the proper solution should be ability to specify the\n> > > desired namespace for any remote repository, like this:\n> > > \n> > > remote..tagNameSpace = foo\n> > \n> > Interesting. I'm not sure what \"foo\" means in this context. Would I use\n> > it\n> > \n> > like this?:\n> > remote.origin.tagNameSpace = refs/tags\n> \n> I was not sure about the specific when I wrote this, so I just put \"foo\",\n> but it could be something like you wrote above.\n> \n> > (to place origin's tags in refs/tags/*)\n> > \n> > If so, what's the difference between this option, and using this?:\n> > remote.origin.fetch = refs/tags/*:refs/tags/*\n> \n> I have not tried that, but I suspect that it will cause that all tags\n> will be fetched even if they are not belong to tracked branches, i.e.\n> \"git fetch\" will work as \"git fetch -t\". But maybe I am wrong here.\n\nAh, yes, I should have been more specific:\n\n remote.origin.fetch = ~refs/tags/*:refs/tags/*\n\nIn my proposal, I suggest using a \"~\" prefix to signal auto-following \nbehavior. This is needed in order to be able to explicitly specify the \ncurrent fetch behavior in the configuration.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160709","messageId":"20110208191147.GA8675@nibiru.local","threadId":"26377","inReplyTo":"201102080915.27484.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2011-02-08T19:11:48Z","receivedAt":"2011-02-08T19:11:48Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Johan Herland wrote:\n\n> Ah, yes, I should have been more specific:\n> \n> remote.origin.fetch = ~refs/tags/*:refs/tags/*\n> \n> In my proposal, I suggest using a \"~\" prefix to signal auto-following \n> behavior. This is needed in order to be able to explicitly specify the \n> current fetch behavior in the configuration.\n\nUnder the hood, this line could be automatically \"added\" (internally)\nunless some \"fetch.autotag = false\" is given.\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"160716","messageId":"7vzkq6p1ap.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"201102080915.27484.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-08T23:13:50Z","receivedAt":"2011-02-08T23:13:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> Ah, yes, I should have been more specific:\n>\n> remote.origin.fetch = ~refs/tags/*:refs/tags/*\n\nHmmm, I was in the vicinity of builtin/fetch.c:find_non_local_tags()\ntoday, and I had to wonder what the implementation of this would look\nlike....\n"},{"id":"160727","messageId":"201102090224.45397.johan@herland.net","threadId":"26377","inReplyTo":"7vzkq6p1ap.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-09T01:24:45Z","receivedAt":"2011-02-09T01:24:45Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 09 February 2011, Junio C Hamano wrote:\n> Johan Herland writes:\n> > Ah, yes, I should have been more specific:\n> > remote.origin.fetch = ~refs/tags/*:refs/tags/*\n> \n> Hmmm, I was in the vicinity of builtin/fetch.c:find_non_local_tags()\n> today, and I had to wonder what the implementation of this would look\n> like....\n\nAFAIK, find_non_local_tags() is called to produce a list of refs to be auto-\nfollowed. Currently it produces this list by traversing the remote refs, and \nselecting refs that follow all of these criteria:\n\nA. Ref name starts with \"refs/tags\"\n\nB. Ref refers (after peeling) to an object that is either already locally \navailable, or is already on the list of objects to be fetched.\n\nC. Ref name does not already exist locally.\n\n\nNow, here's roughly how I would change it to implement the \"~from:to\"-style \nrefspecs:\n\n0. Change its name from find_non_local_tags() to find_auto_follow_refs().\n\n1. At the top, enumerate the auto-following refspecs \n(\"~refs/tags/*:refs/tags/*\" in this case)\n\n2. When traversing the remote refs, instead of criteria A above, we want to \ncheck if ref->name matches the remote side of any of the auto-following \nrefspecs enumerated in step #1. Skip past all non-matches.\n\n3. Criteria B stays unchanged.\n\n4. When checking criteria C, we want to check against the _local_ side of \nthe matched auto-following refspec.\n\n\nAFAICS, that's pretty much what should be needed. There are some other \nthings to consider as well, but IMHO none of those seem like show stoppers:\n\nFor example, there may be command-line options for making auto-following \nrefspecs explicit (i.e. corresponding to --tags; basically disables the \"~\" \nin the refspec), or disabling auto-following (i.e. corresponding to --no-\ntags; basically disregards refspecs with \"~\").\n\nAnother slight complication is refspecs with _both_ \"~\" and \"+\" (i.e. both \nauto-following and --force behavior), which may be resolved by disregarding \ncriteria C for those refspecs.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"160899","messageId":"m3mxm28v3i.fsf@localhost.localdomain","threadId":"26377","inReplyTo":"201102080159.02153.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-11T15:13:36Z","receivedAt":"2011-02-11T15:13:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johan Herland writes:\n> On Monday 07 February 2011, Jeff King wrote:\n> > On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote:\n\n> > > This is the same technique we use when talking about branch names: On\n> > > this mailing list, nobody is confused when I refer to 'maint',\n> > > 'master', 'next' and 'pu'. Still, in our own work repos (at least in\n> > > mine), these branches are actually called \"refs/remotes/origin/\"\n> > > (commonly referred to by their shorthands \"origin/\"). Here we\n> > > are, juggling the same kind of namespaces that I propose for tags, and\n> > > it seems to work well without causing much confusion.\n> > \n> > Just playing devil's advocate for a moment: isn't this namespace\n> > distinction one of the more confusing things in git for new users? That\n> > is, I have seen new-ish git users say \"OK, so I cloned from upstream.\n> > How come I can't say \"git log maint\" now?\"\n\nOr \"where are all the branches?\" ('git branch' doesn't show\nremote-tracking branches).\n\n> > Or it used to be \"how come I can't \"git checkout maint\" now?\" The\n> > latter is now handled by some very specific magic in \"git\n> > checkout\", but in general ref lookup does not automagically look\n> > in remotes namespaces, and it has caused some confusion.\n\nOne has to be very careful with DWIM-mery, lest it would increase\nconfusion instead of reducing it.\n\n[...]\n\n> First, although the separate-remotes may at first be confusing to newbies \n> coming from a centralized VCS, I don't think this is the _main_ source of \n> confusion. And, as you imply, we cannot eliminate this kind of conceptual \n> confusion in any case, without violating core DVCS principles (like Bazaar \n> does in its \"centralized workflow\"). The best way to address this is, as you \n> say, by keeping it \"simple, orthogonal, and distributed\" (and try very hard \n> to keep the common use cases minimally affected).\n\nWell, I think the confusion was greater and more dangerous in\npre-separate remotes era ('master' mapped to 'origin', branches mapped\nto themselves, for single 'origin' remote).\n\n> - Lack of consistency in the ref namespace (refs/remotes/$remote/* vs. \n> refs/tags/*). Also not clear from the current layout where to add new types \n> of refs (e.g. notes, replace). My proposal tries to address this issue.\n\nThe lack of consistency is there because tags should USUALLY be global\n(there should be only one v1.7.4), while branch names should be local\n(my 'master' branch is not your 'master' branch).\n \nIn some cases, like joining or subtree-merging unrelated projects we\nwould want local / per-remote tags: 'v1.7.4' in main project is not\n'v1.7.4' in 'foo' subproject (in 'foo' remote). Currently we lack a\nway to specify that (the 'autofollow' refspec proposal, default\nbehaviour would be equivalent to '~refs/tags/*:refs/tags/*\"), and lack\nsupport from porcelain: MY PROPOSAL is to add '--use-separate-tags'\n(like old '--use-separate-remote') to \"git clone\" and \"git remote add\",\nand perhaps '--alternate' as equivalent to '--no-separate-tags' to \n\"git remote add\".\n\n> - Lack of consistency in which fetch refspecs must be listed in the \n> configuration. (i.e. implicit vs. explicit fetch refspecs). My proposal \n> tries to address this as well.\n\nCould you repeat your proposal? Do I remember it correctly that with\n'autofollow' refspec (valid only for tags... well, perhaps also for\nnotes and replacements) you want to specify defaults in config\nexplicitely\n\n [remote \"origin\"]\n url = git://git.example.com/repo.git\n fetch = +refs/heads/*:refs/remotes/origin/*\n fetch = ~refs/tags/*:refs/tags/*\n\nPerhaps with\n\n fetch = +refs/heads/*:refs/remotes/origin/heads/*\n\n> \n> - Lack of consistency in porcelain interfaces. Some of these have been fixed \n> in recent Git version, but some are yet to be fixed: E.g. some find the use \n> of FETCH_HEAD confusing (when does fetch update the remote refs, and when \n> does it update FETCH_HEAD instead?).\n\nOne of problems is how to keep the fact that\n\n $ git pull \n\ndoes one-off pull without creating remote or remote-tracking branch.\nBut I agree that behavior of\n\n $ git pull \n\ncan be confusing.\n\n> Others (myself included) wonder why 'git push' by default updates\n> remote branches with matching names, while 'git pull' relies on the\n> explicitly configured upstreams to update the local refs. (FWIW,\n> I've mitigated this last complaint insisting that all users at\n> $dayjob run \"git config --global push.default tracking\" immediately\n> after installing Git.) There are other UI inconsistencies too that\n> escape me ATM.\n\nIMHO that's not inconsisnency in Git, this is just reflection of the\nfact that in most common case the situation is *assymetric* with\nrespect to fetch and push; you fetch from other people repositories,\nbut you push to (usually single, perhaps mirrored) your own publishing\nrepository. For this situation 'push.default = matching' works\nperfectly.\n\n> \n> When it comes to your second question, I believe it's definitely worth \n> looking closer at whether we can exploit unambiguity across namespaces for \n> all types of refs (not just tags). I expect there are some non-trivial \n> issues down that road (some of these being discussed elsewhere in this \n> thread), but we may still end up with something better.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"161019","messageId":"201102140036.42197.johan@herland.net","threadId":"26377","inReplyTo":"m3mxm28v3i.fsf@localhost.localdomain","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-13T23:36:41Z","receivedAt":"2011-02-13T23:36:41Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Friday 11 February 2011, Jakub Narebski wrote:\n> Johan Herland writes:\n> > - Lack of consistency in the ref namespace (refs/remotes/$remote/* vs.\n> > refs/tags/*). Also not clear from the current layout where to add new\n> > types of refs (e.g. notes, replace). My proposal tries to address this\n> > issue.\n> \n> The lack of consistency is there because tags should USUALLY be global\n> (there should be only one v1.7.4), while branch names should be local\n> (my 'master' branch is not your 'master' branch).\n>\n> In some cases, like joining or subtree-merging unrelated projects we\n> would want local / per-remote tags: 'v1.7.4' in main project is not\n> 'v1.7.4' in 'foo' subproject (in 'foo' remote). Currently we lack a\n> way to specify that (the 'autofollow' refspec proposal, default\n> behaviour would be equivalent to '~refs/tags/*:refs/tags/*\"), and lack\n> support from porcelain: MY PROPOSAL is to add '--use-separate-tags'\n> (like old '--use-separate-remote') to \"git clone\" and \"git remote add\",\n> and perhaps '--alternate' as equivalent to '--no-separate-tags' to\n> \"git remote add\".\n\nThat requires you to know about the (potential) tag collision (and remember \nto use your option) before fetching from the remote repo.\n\nAlso, even with your added option - which we can use when interfacing \nunrelated projects from a single repo - the expectation (common case) is \nstill that Git will pollute your local tag namespace with remote tags. Some \nof us consider this a bug/misfeature in its own right. And we hold that \nopinion while still agreeing with you that tags \"should USUALLY be global\".\n\n> > - Lack of consistency in which fetch refspecs must be listed in the\n> > configuration. (i.e. implicit vs. explicit fetch refspecs). My proposal\n> > tries to address this as well.\n> \n> Could you repeat your proposal?\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165885\n\n> Do I remember it correctly that with\n> 'autofollow' refspec (valid only for tags... well, perhaps also for\n> notes and replacements) you want to specify defaults in config\n> explicitely\n> \n> [remote \"origin\"]\n> url = git://git.example.com/repo.git\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> fetch = ~refs/tags/*:refs/tags/*\n\nYes, replicating existing behavior w/explicit refspecs would look like this:\n\n [remote \"origin\"]\n url = git://git.example.com/repo.git\n fetch = +HEAD:refs/remotes/origin/HEAD\n fetch = +refs/heads/*:refs/remotes/origin/*\n fetch = ~refs/tags/*:refs/tags/*\n\n> Perhaps with\n> \n> fetch = +refs/heads/*:refs/remotes/origin/heads/*\n\nFTR, my new/proposed refspecs would look like this:\n\n [remote \"origin\"]\n url = git://git.example.com/repo.git\n fetch = +HEAD:refs/remotes/origin/HEAD\n fetch = +refs/heads/*:refs/remotes/origin/heads*\n fetch = ~+refs/tags/*:refs/remotes/origin/tags/*\n ( fetch = +refs/notes/*:refs/remotes/origin/notes/* )\n ( fetch = +refs/replace/*:refs/remotes/origin/replace/* )\n\n> > - Lack of consistency in porcelain interfaces. Some of these have been\n> > fixed in recent Git version, but some are yet to be fixed: E.g. some\n> > find the use of FETCH_HEAD confusing (when does fetch update the\n> > remote refs, and when does it update FETCH_HEAD instead?).\n> \n> One of problems is how to keep the fact that\n> \n> $ git pull \n> \n> does one-off pull without creating remote or remote-tracking branch.\n> But I agree that behavior of\n> \n> $ git pull \n> \n> can be confusing.\n\nYes, to me it seems intuitive that when you specify (even if \ncorresponds to an existing remote) you do NOT update remote-tracking refs, \nbut if you use , you should ALWAYS update remote-tracking refs. \nOthers may disagree.\n\n> > Others (myself included) wonder why 'git push' by default updates\n> > \n> > remote branches with matching names, while 'git pull' relies on the\n> > explicitly configured upstreams to update the local refs. (FWIW,\n> > I've mitigated this last complaint insisting that all users at\n> > $dayjob run \"git config --global push.default tracking\" immediately\n> > after installing Git.) There are other UI inconsistencies too that\n> > escape me ATM.\n> \n> IMHO that's not inconsisnency in Git, this is just reflection of the\n> fact that in most common case the situation is *assymetric* with\n> respect to fetch and push; you fetch from other people repositories,\n> but you push to (usually single, perhaps mirrored) your own publishing\n> repository. For this situation 'push.default = matching' works\n> perfectly.\n\nIt may seem so, but in my experience it doesn't really work perfectly: Even \nif I fully control the repo I push to, I still want precise control over \nwhat I push there. Sometimes I may working on 'next' and 'master' in \nparallel, and I might have finished and tested some bugfixes on 'master', \nwhile I still have unfinished/untested stuff on 'next'. When I 'git push' \nfrom 'master', I DO NOT want 'next' to be pushed (unless I have explicitly \nasked for it).\n\nIf I'm pushing to a shared repo (a very common workplace setup), this \ndefault is even more potentially damaging (especially if I don't discover \nwhat's actually happening by scanning the output from 'git push').\n\nThis is one area where Git's current default behavior is less conservative \nthan I would like.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"161030","messageId":"7vfwrrukzq.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"201102140036.42197.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T07:35:21Z","receivedAt":"2011-02-14T07:35:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> Yes, replicating existing behavior w/explicit refspecs would look like this:\n>\n> [remote \"origin\"]\n> url = git://git.example.com/repo.git\n> fetch = +HEAD:refs/remotes/origin/HEAD\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> fetch = ~refs/tags/*:refs/tags/*\n\nWhile this is fine, I am not sure about the \"HEAD\" part. Most of the\nprotocol do not convey which branch HEAD points at (instead \"clone\" has to\nguess), which eventually needs to be fixed. Incremental updates via\n\"fetch\" does not touch \"HEAD\" at all by design; unlike the real branch\nheads \"remotes/origin/$branch\" that are used to keep copies of what are at\nthe remote, \"remotes/origin/HEAD\" is meant to be used by the local\nrepository to designate which of the remote branch is considered the\nprimary branch from local repository owner's point of view, primarily so\nthat you can say \"origin\" locally to mean \"origin/next\" by setting the\nsymref origin/HEAD to point at it. In that sense, the guess made by\n\"clone\" is only used to give an initial value.\n\n> FTR, my new/proposed refspecs would look like this:\n>\n> [remote \"origin\"]\n> url = git://git.example.com/repo.git\n> fetch = +HEAD:refs/remotes/origin/HEAD\n> fetch = +refs/heads/*:refs/remotes/origin/heads*\n> fetch = ~+refs/tags/*:refs/remotes/origin/tags/*\n> ( fetch = +refs/notes/*:refs/remotes/origin/notes/* )\n> ( fetch = +refs/replace/*:refs/remotes/origin/replace/* )\n\nI think you meant \"refs/remotes/origin/heads/*\" (note the slash) on the\nRHS of the branch refspecs.\n\nHow's that different from refs/*:refs/remotes/origin/* by the way? Also\nif you give tags a totally separate namespace, I don't see much reason to\nstill give it the \"auto-follow\" semantics. It is far simpler to explain\nif you just fetch all of them and be done with it, no?\n\n> Yes, to me it seems intuitive that when you specify (even if \n> corresponds to an existing remote) you do NOT update remote-tracking refs, \n> but if you use , you should ALWAYS update remote-tracking refs.\n> Others may disagree.\n\nOne argument for disagreement used to be that an explicit fetch of a\nsingle branch was a deliberate way to avoid updating the tracking branch\nbefore examining what has been changed (i.e. \"git fetch origin master\"\nfollowed by \"git log origin/master..FETCH_HEAD\" and hopefully followed by\n\"git pull origin\" or somesuch). But that was before reflog was adopted as\na reliable safety measure, and I don't think people should rely on that\nbehaviour anymore.\n\nI would actually make an even stronger point that people should not base\ntheir workflow on keeping remote tracking refs deliberately stale, which\nis exactly the \"feature\" was meant to be used for. What has happened on\nthe other end has already happened whether you like it or not, and there\nis no point in your locally pretending that it didn't happen. If you\ndon't like the latest update there, you go talk to the party that control\nthe remote and rectify the situation with them. It may involve pushing a\nreverting or correcting commit over there, or in the worst case you simply\nstop pulling from them, forking the project in effect at that point.\n\n> It may seem so, but in my experience it doesn't really work perfectly: Even \n> if I fully control the repo I push to, I still want precise control over \n> what I push there. Sometimes I may working on 'next' and 'master' in \n> parallel, and I might have finished and tested some bugfixes on 'master', \n> while I still have unfinished/untested stuff on 'next'.\n\nYes, I do this all the time and I often say \"git push ko maint master\" (ko\nis my name for the k.org repo). I however don't feel inconvenienced by it\nprecisely because when I make such a push, I _know_ that I want to push\nonly these two branches. Saying \"only these two branches\" explicitly from\nthe command line, and seeing only these two branches go out, are very\nassuring to me. I usually try to be much more organized to make sure all\nfour integration branches satisfy certain preconditions before pushing,\nand I say \"git push ko\" only after I make sure they do.\n\nI consider it is a good UI design to force myself to type more when I am\ndoing something un(der)disciplined and to let me type less when I am\nfollowing a good project hygiene.\n"},{"id":"161035","messageId":"201102141018.46527.johan@herland.net","threadId":"26377","inReplyTo":"7vfwrrukzq.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-14T09:18:46Z","receivedAt":"2011-02-14T09:18:46Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 14 February 2011, Junio C Hamano wrote:\n> Johan Herland writes:\n> > Yes, replicating existing behavior w/explicit refspecs would look like: \n> > [remote \"origin\"]\n> > \n> > url = git://git.example.com/repo.git\n> > fetch = +HEAD:refs/remotes/origin/HEAD\n> > fetch = +refs/heads/*:refs/remotes/origin/*\n> > fetch = ~refs/tags/*:refs/tags/*\n> \n> While this is fine, I am not sure about the \"HEAD\" part. Most of the\n> protocol do not convey which branch HEAD points at (instead \"clone\" has\n> to guess), which eventually needs to be fixed. Incremental updates via\n> \"fetch\" does not touch \"HEAD\" at all by design; unlike the real branch\n> heads \"remotes/origin/$branch\" that are used to keep copies of what are\n> at the remote, \"remotes/origin/HEAD\" is meant to be used by the local\n> repository to designate which of the remote branch is considered the\n> primary branch from local repository owner's point of view, primarily so\n> that you can say \"origin\" locally to mean \"origin/next\" by setting the\n> symref origin/HEAD to point at it. In that sense, the guess made by\n> \"clone\" is only used to give an initial value.\n\nAh, ok. I've misunderstood the purpose of \"remotes/origin/HEAD\" then. Feel \nfree to remove that refspec line from my proposal, and leave it as a \nspecial-purpose thing set up by clone (and maintained by the user \nthereafter).\n\nStill (as I think was recently discussed in another thread), the existence \nof remotes/origin/HEAD _does_ cause problems if the origin remote also has a \nbranch called \"refs/heads/HEAD\" (which would collide when fetched into the \nlocal repo).\n\n> > FTR, my new/proposed refspecs would look like this:\n> > [remote \"origin\"]\n> > \n> > url = git://git.example.com/repo.git\n> > fetch = +HEAD:refs/remotes/origin/HEAD\n> > fetch = +refs/heads/*:refs/remotes/origin/heads*\n> > fetch = ~+refs/tags/*:refs/remotes/origin/tags/*\n> > \n> > ( fetch = +refs/notes/*:refs/remotes/origin/notes/* )\n> > ( fetch = +refs/replace/*:refs/remotes/origin/replace/* )\n> \n> I think you meant \"refs/remotes/origin/heads/*\" (note the slash) on the\n> RHS of the branch refspecs.\n\nIndeed. Thanks for pointing out the typo.\n\n> How's that different from refs/*:refs/remotes/origin/* by the way?\n\nIt's not, except that \"refs/*:refs/remotes/origin/*\" would fetch a too-large \nsuperset. E.g. it would fetch \"refs/remotes/third-party/heads/foo\" into \n\"refs/remotes/origin/remotes/third-party/heads/foo\", which we probably don't \nwant.\n\n> Also\n> if you give tags a totally separate namespace, I don't see much reason to\n> still give it the \"auto-follow\" semantics. It is far simpler to explain\n> if you just fetch all of them and be done with it, no?\n\nAgreed. Also, to quote Peff in http://thread.gmane.org/gmane.comp.version-\ncontrol.git/160503/focus=160726 :\n\n\"Now you could argue that auto-follow is not worth the effort. It is\nsomewhat confusing, and I can't think of a time when it ever actually\nreduced the set of objects I was fetching (as opposed to just fetching\nall tags). But maybe others have use cases where it matters.\"\n\nSo if nobody disagree, I would have no problem with dropping the leading \"~\" \nfrom the refspec, thus disabling auto-following (tracking all tags \nexplicitly instead).\n\n> > Yes, to me it seems intuitive that when you specify (even if\n> > corresponds to an existing remote) you do NOT update\n> > remote-tracking refs, but if you use , you should ALWAYS\n> > update remote-tracking refs. Others may disagree.\n> \n> One argument for disagreement used to be that an explicit fetch of a\n> single branch was a deliberate way to avoid updating the tracking branch\n> before examining what has been changed (i.e. \"git fetch origin master\"\n> followed by \"git log origin/master..FETCH_HEAD\" and hopefully followed by\n> \"git pull origin\" or somesuch). But that was before reflog was adopted\n> as a reliable safety measure, and I don't think people should rely on\n> that behaviour anymore.\n> \n> I would actually make an even stronger point that people should not base\n> their workflow on keeping remote tracking refs deliberately stale, which\n> is exactly the \"feature\" was meant to be used for. What has happened on\n> the other end has already happened whether you like it or not, and there\n> is no point in your locally pretending that it didn't happen. If you\n> don't like the latest update there, you go talk to the party that control\n> the remote and rectify the situation with them. It may involve pushing a\n> reverting or correcting commit over there, or in the worst case you\n> simply stop pulling from them, forking the project in effect at that\n> point.\n\nAgreed.\n\n> > It may seem so, but in my experience it doesn't really work perfectly:\n> > Even if I fully control the repo I push to, I still want precise\n> > control over what I push there. Sometimes I may working on 'next' and\n> > 'master' in parallel, and I might have finished and tested some\n> > bugfixes on 'master', while I still have unfinished/untested stuff on\n> > 'next'.\n> \n> Yes, I do this all the time and I often say \"git push ko maint master\"\n> (ko is my name for the k.org repo). I however don't feel inconvenienced\n> by it precisely because when I make such a push, I _know_ that I want to\n> push only these two branches. Saying \"only these two branches\"\n> explicitly from the command line, and seeing only these two branches go\n> out, are very assuring to me. I usually try to be much more organized\n> to make sure all four integration branches satisfy certain preconditions\n> before pushing, and I say \"git push ko\" only after I make sure they do.\n> \n> I consider it is a good UI design to force myself to type more when I am\n> doing something un(der)disciplined and to let me type less when I am\n> following a good project hygiene.\n\nI don't doubt that the current behavior works well for you (otherwise I \nexpect you would have changed it). However, what I've seen at $dayjob is \nthat more inexperienced users will often push right after committing, and at \nthat time they're still very much in the \"working-on-one-branch\" state of \nmind (as opposed to the \"administering-multiple-branches\" state of mind), so \nwhen they follow up a \"git commit\" with a \"git push\" they're surprised (or \nworse: oblivious) to the fact that \"git push\" can push multiple branches.\n\nI guess it comes down to whether you fundamentally consider \"git push\" \nsomething that pushes multiple _branches_, or something that pushes multiple \n_commits_. And for the latter of those groups push.default == \"matching\" is \ninherently more \"dangerous\" than for the former. (Granted, me telling \neveryone to use push.default == \"tracking\" probably doesn't help them in \ndiscovering \"git push\"'s ability to update multiple branches.)\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"161036","messageId":"201102141040.35819.jnareb@gmail.com","threadId":"26377","inReplyTo":"201102140036.42197.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-14T09:40:32Z","receivedAt":"2011-02-14T09:40:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 14 Feb 2011, Johan Herland wrote:\n> On Friday 11 February 2011, Jakub Narebski wrote:\n> > Johan Herland writes:\n\n> > > - Lack of consistency in the ref namespace (refs/remotes/$remote/* vs.\n> > > refs/tags/*). Also not clear from the current layout where to add new\n> > > types of refs (e.g. notes, replace). My proposal tries to address this\n> > > issue.\n> > \n> > The lack of consistency is there because tags should USUALLY be global\n> > (there should be only one v1.7.4), while branch names should be local\n> > (my 'master' branch is not your 'master' branch).\n> >\n> > In some cases, like joining or subtree-merging unrelated projects we\n> > would want local / per-remote tags: 'v1.7.4' in main project is not\n> > 'v1.7.4' in 'foo' subproject (in 'foo' remote). Currently we lack a\n> > way to specify that (the 'autofollow' refspec proposal, default\n> > behaviour would be equivalent to '~refs/tags/*:refs/tags/*\"), and lack\n> > support from porcelain: MY PROPOSAL is to add '--use-separate-tags'\n> > (like old '--use-separate-remote') to \"git clone\" and \"git remote add\",\n> > and perhaps '--alternate' as equivalent to '--no-separate-tags' to\n> > \"git remote add\".\n> \n> That requires you to know about the (potential) tag collision (and remember \n> to use your option) before fetching from the remote repo.\n\nNo, what you need to know at te point of adding remote with \"git remote add\"\nis to know whether the repository is alternative / extra repository of the\nsame project (common tags), or whether it is separate project (separate\ntags).\n\nWhich you should know at this point.\n \n> Also, even with your added option - which we can use when interfacing \n> unrelated projects from a single repo - the expectation (common case) is \n> still that Git will pollute your local tag namespace with remote tags. Some \n> of us consider this a bug/misfeature in its own right. And we hold that \n> opinion while still agreeing with you that tags \"should USUALLY be global\".\n\nI don't think the distinction is between local and per-remote tags. It\nis about local (your own) bookmarking tags versus global repository tags\n(_not_ per-remote) for marking releases.\n\nI guess that current layout might be not best, but per-remote tags isn't it\neither, in my opinion.\n\n\nPlease consider this use case:\n\nLet's assume that current maintainer steps aside for a bit, and new interim\ntemporary maintainer takes mantle. One would add new remote _temporarily_,\nbut one would want for tags that temporary maintainer created to be as good\nas tags from 'origin' remote... and not be deleted when you remove temp\nremote and its remote-tracking branches.\n\n[...]\n> > Do I remember it correctly that with\n> > 'autofollow' refspec (valid only for tags... well, perhaps also for\n> > notes and replacements) you want to specify defaults in config\n> > explicitely\n> > \n> > [remote \"origin\"]\n> > url = git://git.example.com/repo.git\n> > fetch = +refs/heads/*:refs/remotes/origin/*\n> > fetch = ~refs/tags/*:refs/tags/*\n> \n> Yes, replicating existing behavior w/explicit refspecs would look like this:\n> \n> [remote \"origin\"]\n> url = git://git.example.com/repo.git\n> fetch = +HEAD:refs/remotes/origin/HEAD\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> fetch = ~refs/tags/*:refs/tags/*\n\nI'm not sure about HEAD refspec; we don't have one for transferring symrefs.\n\"git push HEAD\" doesn't push HEAD ut the current branch.\n\n[...]\n> > > - Lack of consistency in porcelain interfaces. Some of these have been\n> > > fixed in recent Git version, but some are yet to be fixed: E.g. some\n> > > find the use of FETCH_HEAD confusing (when does fetch update the\n> > > remote refs, and when does it update FETCH_HEAD instead?).\n> > \n> > One of problems is how to keep the fact that\n> > \n> > $ git pull \n> > \n> > does one-off pull without creating remote or remote-tracking branch.\n> > But I agree that behavior of\n> > \n> > $ git pull \n> > \n> > can be confusing.\n> \n> Yes, to me it seems intuitive that when you specify (even if \n> corresponds to an existing remote) you do NOT update remote-tracking refs, \n> but if you use , you should ALWAYS update remote-tracking refs. \n> Others may disagree.\n\nI agree. Keeping remote-tracking branches stale on purpose doesn't look\nfor me like a sane workflow.\n\n> > > Others (myself included) wonder why 'git push' by default updates\n> > > \n> > > remote branches with matching names, while 'git pull' relies on the\n> > > explicitly configured upstreams to update the local refs. (FWIW,\n> > > I've mitigated this last complaint insisting that all users at\n> > > $dayjob run \"git config --global push.default tracking\" immediately\n> > > after installing Git.) There are other UI inconsistencies too that\n> > > escape me ATM.\n> > \n> > IMHO that's not inconsistency in Git, this is just reflection of the\n> > fact that in most common case the situation is *assymetric* with\n> > respect to fetch and push; you fetch from other people repositories,\n> > but you push to (usually single, perhaps mirrored) your own publishing\n> > repository. For this situation 'push.default = matching' works\n> > perfectly.\n> \n> It may seem so, but in my experience it doesn't really work perfectly: Even \n> if I fully control the repo I push to, I still want precise control over \n> what I push there. Sometimes I may working on 'next' and 'master' in \n> parallel, and I might have finished and tested some bugfixes on 'master', \n> while I still have unfinished/untested stuff on 'next'. When I 'git push' \n> from 'master', I DO NOT want 'next' to be pushed (unless I have explicitly \n> asked for it).\n\nThen do \"git push HEAD\" to push current branch only in this\n*special case* (I think there was proposal to have \"git push HEAD\" to\npush to default remote, but I don't know if it was accepted; well, this\nidea can be resurrected if it isn't in).\n\n> If I'm pushing to a shared repo (a very common workplace setup), this \n> default is even more potentially damaging (especially if I don't discover \n> what's actually happening by scanning the output from 'git push').\n> \n> This is one area where Git's current default behavior is less conservative \n> than I would like.\n\nI think that it would be good idea to have \"git push --ask\", which when on\nterminal would present you with the list of branches that would be pushed,\nand ask for confirmation if you push more than one branch or something\n(or perhaps even \"git push --interactive\").\n\nBut this requires some discipline to *not* do work in progress on \npublished branches (matching).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"161037","messageId":"201102141059.12962.jnareb@gmail.com","threadId":"26377","inReplyTo":"201102141018.46527.johan@herland.net","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-14T09:59:12Z","receivedAt":"2011-02-14T09:59:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 14 Feb 2011, Johan Herland wrote:\n> On Monday 14 February 2011, Junio C Hamano wrote:\n>> Johan Herland writes:\n\n>>> Yes, replicating existing behavior w/explicit refspecs would look like: \n>>> [remote \"origin\"]\n>>> \n>>> url = git://git.example.com/repo.git\n>>> fetch = +HEAD:refs/remotes/origin/HEAD\n\nPerhaps\n\n setHead = master\n\nor something like that?\n\n>>> fetch = +refs/heads/*:refs/remotes/origin/*\n>>> fetch = ~refs/tags/*:refs/tags/*\n>> \n>> While this is fine, I am not sure about the \"HEAD\" part. Most of the\n>> protocol do not convey which branch HEAD points at (instead \"clone\" has\n>> to guess), which eventually needs to be fixed.\n\nRight.\n\n>> Incremental updates via \n>> \"fetch\" does not touch \"HEAD\" at all by design; unlike the real branch\n>> heads \"remotes/origin/$branch\" that are used to keep copies of what are\n>> at the remote, \"remotes/origin/HEAD\" is meant to be used by the local\n>> repository to designate which of the remote branch is considered the\n>> primary branch from local repository owner's point of view, primarily so\n>> that you can say \"origin\" locally to mean \"origin/next\" by setting the\n>> symref origin/HEAD to point at it. In that sense, the guess made by\n>> \"clone\" is only used to give an initial value.\n\nWell, we have \"git remote set-branch -a\" to re-do this guessing\nor checking, and update 'remotes/origin/HEAD'...\n\n> \n> Ah, ok. I've misunderstood the purpose of \"remotes/origin/HEAD\" then. Feel \n> free to remove that refspec line from my proposal, and leave it as a \n> special-purpose thing set up by clone (and maintained by the user \n> thereafter).\n\nSee above for my `remote..setHead` proposal.\n\n> Still (as I think was recently discussed in another thread), the existence \n> of remotes/origin/HEAD _does_ cause problems if the origin remote also has a \n> branch called \"refs/heads/HEAD\" (which would collide when fetched into the \n> local repo).\n\nTrue, though... can't we consider having branch named 'HEAD' as insane?\n\n> \n>>> FTR, my new/proposed refspecs would look like this:\n>>> [remote \"origin\"]\n>>> \n>>> url = git://git.example.com/repo.git\n>>> fetch = +HEAD:refs/remotes/origin/HEAD\n>>> fetch = +refs/heads/*:refs/remotes/origin/heads*\n>>> fetch = ~+refs/tags/*:refs/remotes/origin/tags/*\n>>> \n>>> ( fetch = +refs/notes/*:refs/remotes/origin/notes/* )\n>>> ( fetch = +refs/replace/*:refs/remotes/origin/replace/* )\n>> \n>> I think you meant \"refs/remotes/origin/heads/*\" (note the slash) on the\n>> RHS of the branch refspecs.\n> \n> Indeed. Thanks for pointing out the typo.\n> \n>> How's that different from refs/*:refs/remotes/origin/* by the way?\n> \n> It's not, except that \"refs/*:refs/remotes/origin/*\" would fetch a too-large \n> superset. E.g. it would fetch \"refs/remotes/third-party/heads/foo\" into \n> \"refs/remotes/origin/remotes/third-party/heads/foo\", which we probably don't \n> want.\n\nNote that it is not given that notes and replaces should be per-remote\nlike remote-tracking branches, and not autofollowed like tags.\n\n>> Also\n>> if you give tags a totally separate namespace, I don't see much reason to\n>> still give it the \"auto-follow\" semantics. It is far simpler to explain\n>> if you just fetch all of them and be done with it, no?\n> \n> Agreed. Also, to quote Peff in http://thread.gmane.org/gmane.comp.version-\n> control.git/160503/focus=160726 :\n> \n> \"Now you could argue that auto-follow is not worth the effort. It is\n> somewhat confusing, and I can't think of a time when it ever actually\n> reduced the set of objects I was fetching (as opposed to just fetching\n> all tags). But maybe others have use cases where it matters.\"\n> \n> So if nobody disagree, I would have no problem with dropping the leading \"~\" \n> from the refspec, thus disabling auto-following (tracking all tags \n> explicitly instead).\n\nWell, to make use of somewhat contrived example: with current auto-follow\nfetching of tags, when somebody tracks e.g. only 'maint' branch, he/she\nwouldn't get \"*-rcN\" tags he/she is not interested in.\n\nWorth preserving?\n\n[...] \n> I don't doubt that the current behavior works well for you (otherwise I \n> expect you would have changed it). However, what I've seen at $dayjob is \n> that more inexperienced users will often push right after committing, and at \n> that time they're still very much in the \"working-on-one-branch\" state of \n> mind (as opposed to the \"administering-multiple-branches\" state of mind), so \n> when they follow up a \"git commit\" with a \"git push\" they're surprised (or \n> worse: oblivious) to the fact that \"git push\" can push multiple branches.\n> \n> I guess it comes down to whether you fundamentally consider \"git push\" \n> something that pushes multiple _branches_, or something that pushes multiple \n> _commits_. And for the latter of those groups push.default == \"matching\" is \n> inherently more \"dangerous\" than for the former. (Granted, me telling \n> everyone to use push.default == \"tracking\" probably doesn't help them in \n> discovering \"git push\"'s ability to update multiple branches.)\n\nAnother solution is to tech them \"topic branch\" workflow, i.e. to do new\nwork on new feature branch, and only when it is ready merge it into one\nof published branches (i.e. those that have matching branch in remote \nrepository they push to).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"161065","messageId":"4D594E32.3090208@xiplink.com","threadId":"26377","inReplyTo":"201102141040.35819.jnareb@gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-02-14T15:45:54Z","receivedAt":"2011-02-14T15:45:54Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-02-14 04:40 AM, Jakub Narebski wrote:\n> On Mon, 14 Feb 2011, Johan Herland wrote:\n>> On Friday 11 February 2011, Jakub Narebski wrote:\n>>> Johan Herland writes:\n> \n>>>> - Lack of consistency in the ref namespace (refs/remotes/$remote/* vs.\n>>>> refs/tags/*). Also not clear from the current layout where to add new\n>>>> types of refs (e.g. notes, replace). My proposal tries to address this\n>>>> issue.\n>>>\n>>> The lack of consistency is there because tags should USUALLY be global\n>>> (there should be only one v1.7.4), while branch names should be local\n>>> (my 'master' branch is not your 'master' branch).\n>>>\n>>> In some cases, like joining or subtree-merging unrelated projects we\n>>> would want local / per-remote tags: 'v1.7.4' in main project is not\n>>> 'v1.7.4' in 'foo' subproject (in 'foo' remote). Currently we lack a\n>>> way to specify that (the 'autofollow' refspec proposal, default\n>>> behaviour would be equivalent to '~refs/tags/*:refs/tags/*\"), and lack\n>>> support from porcelain: MY PROPOSAL is to add '--use-separate-tags'\n>>> (like old '--use-separate-remote') to \"git clone\" and \"git remote add\",\n>>> and perhaps '--alternate' as equivalent to '--no-separate-tags' to\n>>> \"git remote add\".\n>>\n>> That requires you to know about the (potential) tag collision (and remember \n>> to use your option) before fetching from the remote repo.\n> \n> No, what you need to know at te point of adding remote with \"git remote add\"\n> is to know whether the repository is alternative / extra repository of the\n> same project (common tags), or whether it is separate project (separate\n> tags).\n> \n> Which you should know at this point.\n> \n>> Also, even with your added option - which we can use when interfacing \n>> unrelated projects from a single repo - the expectation (common case) is \n>> still that Git will pollute your local tag namespace with remote tags. Some \n>> of us consider this a bug/misfeature in its own right. And we hold that \n>> opinion while still agreeing with you that tags \"should USUALLY be global\".\n> \n> I don't think the distinction is between local and per-remote tags. It\n> is about local (your own) bookmarking tags versus global repository tags\n> (_not_ per-remote) for marking releases.\n> \n> I guess that current layout might be not best, but per-remote tags isn't it\n> either, in my opinion.\n> \n> \n> Please consider this use case:\n> \n> Let's assume that current maintainer steps aside for a bit, and new interim\n> temporary maintainer takes mantle. One would add new remote _temporarily_,\n> but one would want for tags that temporary maintainer created to be as good\n> as tags from 'origin' remote... and not be deleted when you remove temp\n> remote and its remote-tracking branches.\n\nI take it that \"origin\" here refers to the first maintainer's repository.\n\nI suggest that the correct thing to do in this case is to change the URL of\nthe \"origin\" remote. Because really that's what you want: the temp\nmaintainer's repo is the equivalent of the first maintainer's repo. When the\nfirst maintainer returns he'll update his own repo to match the temp\nmaintainer's, then everyone can switch their remotes back to the original\nrepo. (Perhaps git-remote could even learn an \"import-tags\" subcommand to\nhelp the original maintainer here.)\n\nFor me, having more than one remote be *simultaneously* authoritative for a\nset of tags is the unusual case. I find that most projects, no matter how\ndecentralized, need to agree upon the project's \"official\" history, and that\nsuch agreement is almost always encapsulated within a single, \"official\"\nrepository. To have more than one is, frankly, insane.\n\nSo to me it seems completely natural to think of a project's \"official\" tags\nas the ones that are obtained from the project's \"official\" repository. It\nfollows that tags should subscribe to the same remote-ref model as branches.\n The benefits are powerful: consistency; deals naturally with imported\nhistories from different repositories; and allows automatic propagation of\nupdated (i.e. moved) tags from remotes to clones (yes tags *should* never\nmove, but they do, often for good reason and occasionally as part of a\nproject's natural evolution).\n\nThere have been several comments disparaging per-remote tags, but people are\nclearly dissatisfied with the status quo. Can anyone propose another\nalternative?\n\n\t\tM.\n"},{"id":"161076","messageId":"7voc6ettgk.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"201102141059.12962.jnareb@gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T17:30:03Z","receivedAt":"2011-02-14T17:30:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> On Mon, 14 Feb 2011, Johan Herland wrote:\n>>>> Yes, replicating existing behavior w/explicit refspecs would look like: \n>>>> [remote \"origin\"]\n>>>> \n>>>> url = git://git.example.com/repo.git\n>>>> fetch = +HEAD:refs/remotes/origin/HEAD\n>\n> Perhaps\n>\n> setHead = master\n>\n> or something like that?\n\nIf I understand what Johan is saying correctly, I don't think that is\nsolving any conceived problems. Currently origin/HEAD once initialized\ndoes not repoint and that behaviour more or less has been kept on\npurpose.\n\nWhat it allows us by explicitly saying HEAD in the refspecs is to move\naway from the \"origin/HEAD is under control of the local repository---it\ndetermines what you as the cloner consider the primary branch you are\ninterested in in this particular remote\" semantics and instead start\nsaying \"just like we copy the values of normal refs from the other side to\nkeep track, we want origin/HEAD to _point at_ the branch they pointed at\nwhen we looked at them the last time\". While I personally think that is\nalso a valid thing to wish for, it probably is a bit too big a change in\nthe semantics at this point.\n\nIf you mean by \"setHead = master\" to \"set origin/HEAD symref to point at\ntheir master\", that does not have to live in the config at all. Once you\npoint the symref, nobody will repoint it to anywhere.\n\n>>> ... is meant to be used by the local\n>>> repository to designate which of the remote branch is considered the\n>>> primary branch from local repository owner's point of view, primarily so\n>>> that you can say \"origin\" locally to mean \"origin/next\" by setting the\n>>> symref origin/HEAD to point at it....\n>\n> Well, we have \"git remote set-branch -a\" to re-do this guessing\n> or checking, and update 'remotes/origin/HEAD'...\n\nThat is exactly what I said, isn't it?\n\n>> Still (as I think was recently discussed in another thread), the existence \n>> of remotes/origin/HEAD _does_ cause problems if the origin remote also has a \n>> branch called \"refs/heads/HEAD\" (which would collide when fetched into the \n>> local repo).\n>\n> True, though... can't we consider having branch named 'HEAD' as insane?\n\nThere was a discussion to forbid ([ANYTHING_0-9A-Z]*_)?HEAD as a branch\nname to reduce confusion, and I think that is probably a sane thing to do\nwithout harming anybody in practice.\n"},{"id":"161079","messageId":"7vfwrqtrsk.fsf_-_@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"201102141018.46527.johan@herland.net","subject":"Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T18:06:03Z","receivedAt":"2011-02-14T18:06:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> It's not, except that \"refs/*:refs/remotes/origin/*\" would fetch a too-large \n> superset. E.g. it would fetch \"refs/remotes/third-party/heads/foo\" into \n> \"refs/remotes/origin/remotes/third-party/heads/foo\", which we probably don't \n> want.\n\nAh, very true. We are generally not interested in remote's remotes that\npossibly include ourselves ;-)\n\n> \"Now you could argue that auto-follow is not worth the effort. It is\n> somewhat confusing, and I can't think of a time when it ever actually\n> reduced the set of objects I was fetching (as opposed to just fetching\n> all tags). But maybe others have use cases where it matters.\"\n>\n> So if nobody disagree, I would have no problem with dropping the leading \"~\" \n> from the refspec, thus disabling auto-following (tracking all tags \n> explicitly instead).\n\nI am not sure what you mean by this. I think we agree that it would be Ok\nif you cannot add \"~\" in front to cause automatic following when tracking\ntags in separate namespaces using \"refs/tags/*:refs/remotes/origin/tags/*\".\n\nBut are you saying:\n\n (1) There is no other change than that; or\n\n (2) Even when not using such a refspec i.e. using the traditional \"tags\n live in a single global namespace\", automatic following feature will\n be disabled;\n\nI would be moderately unhappy if the latter.\n\n> ... However, what I've seen at $dayjob is \n> that more inexperienced users will often push right after committing, and at \n> that time they're still very much in the \"working-on-one-branch\" state of \n> mind (as opposed to the \"administering-multiple-branches\" state of mind),...\n\nThen \"current\" mode is a good setting for them, I would presume. I don't\nthink it is a bad idea to make that the default given sufficient lead time\nto warn the current users, and if we want to make the switch at 1.8.0, the\ntime to start issuing a warning is now. Perhaps like this.\n\n-- >8 --\nSubject: [1.8.0 RFC] push: start warning upcoming default change for push.default\n\nMore inexperienced users will often push right after committing, and at\nthat time they're still very much in the \"working-on-one-branch\" state of\nmind. \"current\" would be a safer default mode of operation for 'git push'\nfor them even when they have their personal publishing repository (also in\na shared public repository settings, \"matching\" is rarely the right\ndefault mode).\n\nIn preparation for flipping the default to the \"current\" mode from the\n\"matching\" mode that is the current default, start warning users when they\nrely on unconfigured \"git push\" to default to the \"matching\" mode.\n\nSigned-off-by: Junio C Hamano \n---\n builtin/push.c | 13 +++++++++++++\n cache.h | 1 +\n environment.c | 2 +-\n 3 files changed, 15 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex e655eb7..fe6665e 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -80,10 +80,23 @@ static void setup_push_tracking(void)\n \tadd_refspec(refspec.buf);\n }\n \n+static void warn_unspecified_push_default_configuration(void)\n+{\n+\tstatic int warn_once;\n+\n+\tif (warn_once++)\n+\t\treturn;\n+\twarning(\"You do not have an explicit 'matching' setting for push.default\");\n+\twarning(\"Your workflow will be broken at 1.8.0 unless you do so now\");\n+}\n+\n static void setup_default_push_refspecs(void)\n {\n \tswitch (push_default) {\n \tdefault:\n+\tcase PUSH_DEFAULT_UNSPECIFIED:\n+\t\twarn_unspecified_push_default_configuration();\n+\t\t/* fallthru */\n \tcase PUSH_DEFAULT_MATCHING:\n \t\tadd_refspec(\":\");\n \t\tbreak;\ndiff --git a/cache.h b/cache.h\nindex d83d68c..6c47867 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -606,6 +606,7 @@ enum rebase_setup_type {\n };\n \n enum push_default_type {\n+\tPUSH_DEFAULT_UNSPECIFIED = -1,\n \tPUSH_DEFAULT_NOTHING = 0,\n \tPUSH_DEFAULT_MATCHING,\n \tPUSH_DEFAULT_TRACKING,\ndiff --git a/environment.c b/environment.c\nindex 9564475..577177f 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -47,7 +47,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;\n enum rebase_setup_type autorebase = AUTOREBASE_NEVER;\n-enum push_default_type push_default = PUSH_DEFAULT_MATCHING;\n+enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;\n #ifndef OBJECT_CREATION_MODE\n #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS\n #endif\n"},{"id":"161081","messageId":"7vbp2etqne.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"201102141040.35819.jnareb@gmail.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T18:30:45Z","receivedAt":"2011-02-14T18:30:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Please consider this use case:\n>\n> Let's assume that current maintainer steps aside for a bit, and new interim\n> temporary maintainer takes mantle. One would add new remote _temporarily_,\n> but one would want for tags that temporary maintainer created to be as good\n> as tags from 'origin' remote... and not be deleted when you remove temp\n> remote and its remote-tracking branches.\n\nWhy don't you want to delete them?\n\nWhen the \"interim\" maintainer gives the baton back to the authoritative\nmaintainer, the tags that are blessed between these two maintainers will\nsurely be propagated [*1*] to the authoritative repository and you will\nhave them at refs/tags or refs/remotes/origin/tags in your repository.\n\nAnd at that point, if you do not want to have refs/remotes/interim/heads/\nbranches, you surely do not mind cleaning refs/remotes/interim/tags/\nhierarchy as well, no?\n\nHaving said all that, if we assume *1* above, then we wouldn't have needed\nseparate tag namespace in the first place.\n\nFurther, think about the case where the \"interim\" maintainer ends up\nbecoming the authoritative maintainer, which is the same thing as not\nassuming *1* above. You would want to consolidate refs/remotes/origin/tags\nand refs/remotes/interim/tags, and we do not expect any collisions when we do\nso.\n\nWhich suggests that tags namespace is really special in that it does want\nto be globally unique and agreed namespace, unlike branch namespace.\n"},{"id":"161083","messageId":"AANLkTincKapKgcWEE1Z+vQesSjZBFAnfH0uL+a7GhQ6b@mail.gmail.com","threadId":"26377","inReplyTo":"7vfwrqtrsk.fsf_-_@alter.siamese.dyndns.org","subject":"Re: Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-14T18:53:47Z","receivedAt":"2011-02-14T18:53:47Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 14, 2011 at 1:06 PM, Junio C Hamano wrote:\n> +       warning(\"You do not have an explicit 'matching' setting for push.default\");\n> +       warning(\"Your workflow will be broken at 1.8.0 unless you do so now\");\n\nThat message seems like it would confuse a new user. This seems less\nconfusing to me w/o becoming a paragraph of text that no one will\nread:\n\n push.default is unset; its implicit value is changing in 1.8.0. To squelch\n this message, set push.default. See push.default in 'git help config'.\n\nAnd update the git config man page entry for push.default to note that\nmatching is the current default behavior and current will be default\nbehavior starting with 1.8.0\n\n(Aside, it would be nice if \"git help config push.default\" did what I want. :-)\n\nj.\n"},{"id":"161085","messageId":"alpine.LFD.2.00.1102141347460.14920@xanadu.home","threadId":"26377","inReplyTo":"7vbp2etqne.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-14T19:06:57Z","receivedAt":"2011-02-14T19:06:57Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 14 Feb 2011, Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n> > Please consider this use case:\n> >\n> > Let's assume that current maintainer steps aside for a bit, and new interim\n> > temporary maintainer takes mantle. One would add new remote _temporarily_,\n> > but one would want for tags that temporary maintainer created to be as good\n> > as tags from 'origin' remote... and not be deleted when you remove temp\n> > remote and its remote-tracking branches.\n> \n> Why don't you want to delete them?\n> \n> When the \"interim\" maintainer gives the baton back to the authoritative\n> maintainer, the tags that are blessed between these two maintainers will\n> surely be propagated [*1*] to the authoritative repository and you will\n> have them at refs/tags or refs/remotes/origin/tags in your repository.\n> \n> And at that point, if you do not want to have refs/remotes/interim/heads/\n> branches, you surely do not mind cleaning refs/remotes/interim/tags/\n> hierarchy as well, no?\n\nExact.\n\n> Having said all that, if we assume *1* above, then we wouldn't have needed\n> separate tag namespace in the first place.\n\nDepends. There could be multiple compeeting \"interim\" maintainers \neffectively creating forks. They may have conflicting tags. The \n\"official\" maintainer may vet only one of those forks. The other forks \nmay die or have a life of their own, Etc. Etc.\n\n> Further, think about the case where the \"interim\" maintainer ends up\n> becoming the authoritative maintainer, which is the same thing as not\n> assuming *1* above. You would want to consolidate refs/remotes/origin/tags\n> and refs/remotes/interim/tags, and we do not expect any collisions when we do\n> so.\n\nRight. But that's an expectation based on social practices within a \nproject. In theory there _could_ be collisions.\n\nLet's take the OpenOffice vs LibreOffice as an example. What if I want \nboth in my repository so I can easily perform diffs between those \nindependent branches? They may certainly end up producing releases with \nthe same version numbers (same tag name) but different content \n(different tag references).\n\n> Which suggests that tags namespace is really special in that it does want\n> to be globally unique and agreed namespace, unlike branch namespace.\n\nSemantically, yes. but a separate namespace just makes special cases as \nthose shown above so much easier to deal with.\n\nThe separate namespace is a _technical_ implementation detail that makes \nall the ambigous cases easy. It doesn't make the mistake of imposing a \nsocial convention upon people. So whatever people end up collectively \ndoing with their tags is not tied to the tool's limitation anymore.\n\nYou end up with 2 tags with the same name? Fine. If they are identical \nthen you may just as well ignore that they're in separate namespaces. \nThe tool will present things to you as such instead of enforcing that in \nthe data structure (this is just like we do with file renames). If \nthey're different, then at least you now have the possibility to choose \nwhich tag you actually want by prefixing it with its namespace. Right \nnow this is just not possible.\n\nPlease let's not confuse technical details like data (or tag) storage \nwith social conventions.\n\n\nNicolas\n"},{"id":"161087","messageId":"alpine.LFD.2.00.1102141418370.14920@xanadu.home","threadId":"26377","inReplyTo":"4D594E32.3090208@xiplink.com","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-14T19:35:42Z","receivedAt":"2011-02-14T19:35:42Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 14 Feb 2011, Marc Branchaud wrote:\n\n> For me, having more than one remote be *simultaneously* authoritative for a\n> set of tags is the unusual case. I find that most projects, no matter how\n> decentralized, need to agree upon the project's \"official\" history, and that\n> such agreement is almost always encapsulated within a single, \"official\"\n> repository. To have more than one is, frankly, insane.\n\nThat's a social convention, and a pretty sane one indeed.\n\nBUT if this happens not to be the case (think of a project fork) then \nthe tool must not get in the way if you happen to want to track both \nbranches at the same time including their possibly conflicting set of \ntags.\n\nSo having a separate namespace for tags coming from different remotes \nshouldn't make any difference to you when the tool can easily figure out \nthat none of them conflicts with each other.\n\n> So to me it seems completely natural to think of a project's \"official\" tags\n> as the ones that are obtained from the project's \"official\" repository. It\n> follows that tags should subscribe to the same remote-ref model as branches.\n\nThat's exactly what the proposal is about: making remote tags \ndistinguishable per remote, just like branches are.\n\n> The benefits are powerful: consistency; deals naturally with imported\n> histories from different repositories; and allows automatic propagation of\n> updated (i.e. moved) tags from remotes to clones (yes tags *should* never\n> move, but they do, often for good reason and occasionally as part of a\n> project's natural evolution).\n\nSure. But if you follow a single remote like most people do then you \nwon't see the difference from the current state of affairs we have \ntoday.\n\nBut if you do follow multiple remotes related to the same project, and \none of them do move a tag, then you certainly want to be notified of it \nand then have the _choice_ of the actual remote you want to use for the \ntag meaning, and not having that tag become authoritative for all the \nremotes you track, especially if you may end up not agreeing with that \nmove for some reasons.\n\n> There have been several comments disparaging per-remote tags, but people are\n> clearly dissatisfied with the status quo. Can anyone propose another\n> alternative?\n\nPeople have been disparaging the lack of explicit rename tracking in Git \ntoo. IMHO those people disparaging per-remote tags so far did not bring \nany serious solid technical reason for not doing it. Resistance so far \nappears to be based on a fear of change, which change is even not \njustified as people's workflow should remain completely unchanged in the \npresence of duplicate non-conflicting tags encouraged by current social \nconventions.\n\n\nNicolas\n"},{"id":"161091","messageId":"AANLkTi=Fpey7e+E1eKOiSaS1hjW2d8eOy9PVLR34Sc5J@mail.gmail.com","threadId":"26377","inReplyTo":"AANLkTincKapKgcWEE1Z+vQesSjZBFAnfH0uL+a7GhQ6b@mail.gmail.com","subject":"Re: Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-14T19:44:11Z","receivedAt":"2011-02-14T19:44:11Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Feb 14, 2011 at 19:53, Jay Soffian wrote:\n>  push.default is unset; its implicit value is changing in 1.8.0. To squelch\n>  this message, set push.default. See push.default in 'git help config'.\n\nThis is worse than what Junio suggested because it does not tell you\nwhat to set it to.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"161092","messageId":"AANLkTik-6KYYNnTr9cmTuE=QQ7gZwP6qw0=bboGWfcf8@mail.gmail.com","threadId":"26377","inReplyTo":"alpine.LFD.2.00.1102141347460.14920@xanadu.home","subject":"Re: [1.8.0] Provide proper remote ref namespaces","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-14T19:46:52Z","receivedAt":"2011-02-14T19:46:52Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Feb 14, 2011 at 20:06, Nicolas Pitre wrote:\n> Let's take the OpenOffice vs LibreOffice as an example.  What if I want\n> both in my repository so I can easily perform diffs between those\n> independent branches?  They may certainly end up producing releases with\n> the same version numbers (same tag name) but different content\n> (different tag references).\n\nI think this concrete example of a very valid use case shows that we\nshould (in some way or form) implement this :).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"161095","messageId":"AANLkTin5ZcZU8iwPSm4A87bYRrSCcXJVLBFGSr2+j30j@mail.gmail.com","threadId":"26377","inReplyTo":"AANLkTi=Fpey7e+E1eKOiSaS1hjW2d8eOy9PVLR34Sc5J@mail.gmail.com","subject":"Re: Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-14T19:50:17Z","receivedAt":"2011-02-14T19:50:17Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 14, 2011 at 2:44 PM, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Mon, Feb 14, 2011 at 19:53, Jay Soffian wrote:\n>>  push.default is unset; its implicit value is changing in 1.8.0. To squelch\n>>  this message, set push.default. See push.default in 'git help config'.\n>\n> This is worse than what Junio suggested because it does not tell you\n> what to set it to.\n\nWhich was intentional on my part. If the message says what to set it\nto, the beginner will just go 'okay' and set it to that, in which\ncase, what is the point of changing the default? Hence pointing to the\nman page.\n\nAlternately, you could take the wall of text approach, which I was\ntrying to avoid:\n\n push.default is unset; its implicit value is changing in 1.8.0 from\n 'matching' to 'current'. To squelch this message and maintain the current\n behavior post-1.8.0, use 'git config [--global] push.default matching'. To\n squelch this message and adopt the 1.8.0 behavior now, use\n 'git config [--global] push.default current'. See 'git help config' and\n search for 'push.default' for further information.\n\nj.\n"},{"id":"161105","messageId":"20110214212131.GA23806@elie","threadId":"26377","inReplyTo":"AANLkTin5ZcZU8iwPSm4A87bYRrSCcXJVLBFGSr2+j30j@mail.gmail.com","subject":"Re: [1.8.0 RFC] push: start warning upcoming default change for push.default","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-14T21:21:31Z","receivedAt":"2011-02-14T21:21:31Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jay Soffian wrote:\n> On Mon, Feb 14, 2011 at 2:44 PM, Sverre Rabbelier wrote:\n>> On Mon, Feb 14, 2011 at 19:53, Jay Soffian wrote:\n>>> Junio C Hamano wrote:\n\n>>>> +\twarning(\"You do not have an explicit 'matching' setting for push.default\");\n>>>> +\twarning(\"Your workflow will be broken at 1.8.0 unless you do so now\");\n[...]\n>>>  push.default is unset; its implicit value is changing in 1.8.0. To squelch\n>>>  this message, set push.default. See push.default in 'git help config'.\n>>\n>> This is worse than what Junio suggested because it does not tell you\n>> what to set it to.\n>\n> Which was intentional on my part. If the message says what to set it\n> to, the beginner will just go 'okay' and set it to that, in which\n> case, what is the point of changing the default?\n\nWait, why isn't that a good thing? The beginner only has to learn one\nset of semantics. My only complaint is that the warning does not\nexplain how to specify \"squelch this warning and give me the future\nsemantics instead\".\n\nSo maybe:\n\nwarning: You do not have an explicit 'matching' setting for push.default.\nwarning: Your workflow will be broken at 1.8.0 unless you do so now.\nhint: See /usr/share/doc/git/RelNotes/1.7.5.txt for details.\n"},{"id":"161110","messageId":"AANLkTi=_TVB9cUhLa66_om+c_wptDh+kaJH-idp1=s6O@mail.gmail.com","threadId":"26377","inReplyTo":"20110214212131.GA23806@elie","subject":"Re: [1.8.0 RFC] push: start warning upcoming default change for push.default","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-14T21:41:33Z","receivedAt":"2011-02-14T21:41:33Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 14, 2011 at 4:21 PM, Jonathan Nieder wrote:\n>> Which was intentional on my part. If the message says what to set it\n>> to, the beginner will just go 'okay' and set it to that, in which\n>> case, what is the point of changing the default?\n>\n> Wait, why isn't that a good thing?\n\nBecause 'current' is the more sensible default behavior. If everyone\nsets push.default to 'matching' because that's what the message\nadvises, what's the point of changing the implicit default to\n'current'?\n\nj.\n"},{"id":"161115","messageId":"20110214215529.GB24030@elie","threadId":"26377","inReplyTo":"AANLkTi=_TVB9cUhLa66_om+c_wptDh+kaJH-idp1=s6O@mail.gmail.com","subject":"Re: [1.8.0 RFC] push: start warning upcoming default change for push.default","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-14T21:55:29Z","receivedAt":"2011-02-14T21:55:29Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jay Soffian wrote:\n\n> If everyone\n> sets push.default to 'matching' because that's what the message\n> advises, what's the point of changing the implicit default to\n> 'current'?\n\nThat new installations after v1.8.0 would use the more sensible behavior?\n"},{"id":"161116","messageId":"vpqr5bath2z.fsf@bauges.imag.fr","threadId":"26377","inReplyTo":"AANLkTin5ZcZU8iwPSm4A87bYRrSCcXJVLBFGSr2+j30j@mail.gmail.com","subject":"Re: Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-14T21:57:24Z","receivedAt":"2011-02-14T21:57:24Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"First, I'd be really glad if push.default changed to \"current\", that's\nwhat I want 99% of cases, if not more.\n\nJay Soffian writes:\n\n> Alternately, you could take the wall of text approach, which I was\n> trying to avoid:\n>\n> push.default is unset; its implicit value is changing in 1.8.0 from\n> 'matching' to 'current'. To squelch this message and maintain the current\n> behavior post-1.8.0, use 'git config [--global] push.default matching'. To\n> squelch this message and adopt the 1.8.0 behavior now, use\n> 'git config [--global] push.default current'. See 'git help config' and\n> search for 'push.default' for further information.\n\nI actually like this, although it's a bit verbose: I think telling the\nuser \"something will change\" without telling what is very frustrating,\nso the \"from 'matching' to 'current'\" part seems really good.\n\nI'd remove the [] around the --global, to make the command\ncut-and-paste ready. Advanced users know whether to remove the\n--global, and newbies don't want to remove it.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"161123","messageId":"20110214223557.GA13070@sigill.intra.peff.net","threadId":"26377","inReplyTo":"vpqr5bath2z.fsf@bauges.imag.fr","subject":"Re: Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-14T22:35:57Z","receivedAt":"2011-02-14T22:35:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 14, 2011 at 10:57:24PM +0100, Matthieu Moy wrote:\n\n> Jay Soffian writes:\n> \n> > Alternately, you could take the wall of text approach, which I was\n> > trying to avoid:\n> >\n> > push.default is unset; its implicit value is changing in 1.8.0 from\n> > 'matching' to 'current'. To squelch this message and maintain the current\n> > behavior post-1.8.0, use 'git config [--global] push.default matching'. To\n> > squelch this message and adopt the 1.8.0 behavior now, use\n> > 'git config [--global] push.default current'. See 'git help config' and\n> > search for 'push.default' for further information.\n> \n> I actually like this, although it's a bit verbose: I think telling the\n> user \"something will change\" without telling what is very frustrating,\n> so the \"from 'matching' to 'current'\" part seems really good.\n\nI like this one, too. It lays out what is happening and what the\npossible choices are. I don't think we should be afraid of a lot of text\nin a change-of-behavior message like this. It's _supposed_ to be\nannoying and catch their attention, and there are instructions right\nthere for shutting it up.\n\nWe have used this strategy before, and I don't remember anyone\ncomplaining about \"this message is too long\".\n\n> I'd remove the [] around the --global, to make the command\n> cut-and-paste ready. Advanced users know whether to remove the\n> --global, and newbies don't want to remove it.\n\nAgreed, and put the commands on their own line for simpler\ncut-and-paste, like:\n\n push.default is unset; its implicit value is changing in 1.8.0 from\n 'matching' to 'current'. To squelch this message and maintain the\n current behavior post-1.8.0, run:\n\n git config --global push.default matching\n\n To squelch this message and adopt the 1.8.0 behavior now, run:\n\n git config --global push.default current\n\n See 'git help config' and search for 'push.default' for further\n information.\n\nI think the whitespace makes it easier to see there are two choices, and\nmost people have some kind of triple-click-to-copy-whole-line in their\nterminal.\n\n-Peff\n"},{"id":"161124","messageId":"AANLkTikDLV0LC_35aJAiV5LrdQj_2vDkCzOwmwDQ+6YH@mail.gmail.com","threadId":"26377","inReplyTo":"20110214223557.GA13070@sigill.intra.peff.net","subject":"Re: Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-14T22:38:47Z","receivedAt":"2011-02-14T22:38:47Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Feb 14, 2011 at 23:35, Jeff King wrote:\n> I think the whitespace makes it easier to see there are two choices, and\n> most people have some kind of triple-click-to-copy-whole-line in their\n> terminal.\n\n+1 to giving a clear way to choose either the current or the\nnew-default behavior. The only thing I can think of to make it even\nbetter now is to inline the description of what those two modes mean\n;)\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"161127","messageId":"7vvd0mqks7.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"AANLkTi=Fpey7e+E1eKOiSaS1hjW2d8eOy9PVLR34Sc5J@mail.gmail.com","subject":"Re: Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T23:05:44Z","receivedAt":"2011-02-14T23:05:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> On Mon, Feb 14, 2011 at 19:53, Jay Soffian wrote:\n>>  push.default is unset; its implicit value is changing in 1.8.0. To squelch\n>>  this message, set push.default. See push.default in 'git help config'.\n>\n> This is worse than what Junio suggested because it does not tell you\n> what to set it to.\n\nBut the weatherbaloon patch from me was equally bad in another sense. I\nwas only showing where the change should go, and not what the precise\nwording should be.\n\nThe message triggers not just for people who _do_ use and want to keep\nusing matching semantics (iow, old timers), for whom the weatherbaloon\nwording is adequate, but also for people who are new and do not have\nanything configured, majority of which are _suspected_ to be better off\nusing \"current\" setting (if we don't suspect that, we won't be talking\nabout possibly switching the default in the future).\n\nSo I would imagine the actual wording should at least explain that there\nare two plausible choices, and people who want to get used to the upcoming\ndefault earlier would want to set it to \"current\", while others who want to\nkeep the current default would want to set it to \"matching\", to avoid\nsurprises.\n"},{"id":"161132","messageId":"20110214233607.GA25163@elie","threadId":"26377","inReplyTo":"20110214223557.GA13070@sigill.intra.peff.net","subject":"Re: [1.8.0 RFC] push: start warning upcoming default change for push.default","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-14T23:36:07Z","receivedAt":"2011-02-14T23:36:07Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> Agreed, and put the commands on their own line for simpler\n> cut-and-paste, like:\n>\n> push.default is unset; its implicit value is changing in 1.8.0 from\n> 'matching' to 'current'. To squelch this message and maintain the\n> current behavior post-1.8.0, run:\n>\n> git config --global push.default matching\n>\n> To squelch this message and adopt the 1.8.0 behavior now, run:\n>\n> git config --global push.default current\n>\n> See 'git help config' and search for 'push.default' for further\n> information.\n>\n> I think the whitespace makes it easier to see there are two choices, and\n> most people have some kind of triple-click-to-copy-whole-line in their\n> terminal.\n\nYes. Thank you, and sorry about my previous reply that missed the\npoint.\n"},{"id":"161133","messageId":"7vfwrqqiya.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"20110214223557.GA13070@sigill.intra.peff.net","subject":"Re: Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T23:45:17Z","receivedAt":"2011-02-14T23:45:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I like this one, too. It lays out what is happening and what the\n> possible choices are....\n\nHeh, I see others sorted this out while I was looking the other way ;-)\nCare to roll an appliable patch?\n"},{"id":"161191","messageId":"201102151606.21040.johan@herland.net","threadId":"26377","inReplyTo":"7vfwrqtrsk.fsf_-_@alter.siamese.dyndns.org","subject":"Re: Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-15T15:06:20Z","receivedAt":"2011-02-15T15:06:20Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 14 February 2011, Junio C Hamano wrote:\n> Johan Herland writes:\n> > So if nobody disagree, I would have no problem with dropping the\n> > leading \"~\" from the refspec, thus disabling auto-following\n> > (tracking all tags explicitly instead).\n>\n> I am not sure what you mean by this. I think we agree that it would\n> be Ok if you cannot add \"~\" in front to cause automatic following\n> when tracking tags in separate namespaces using\n> \"refs/tags/*:refs/remotes/origin/tags/*\".\n>\n> But are you saying:\n>\n> (1) There is no other change than that; or\n>\n> (2) Even when not using such a refspec i.e. using the traditional\n> \"tags live in a single global namespace\", automatic following feature\n> will be disabled;\n>\n> I would be moderately unhappy if the latter.\n\nNo, I'm saying the former.\n\nFor the foreseeable future (i.e. long after v1.8.0 is out) we will still \nhave to understand and support the traditional \"tags are implicitly \nauto-followed\" and \"tags live in a single global namespace\" concepts \n(aka. (a) below). For new-style remotes I propose that all refspecs be \nexplicit, and that auto-follow is disabled (aka. (b) below).\n\nBut if you try to specify a new-style remote with all tags in a single \nglobal namespace, you will NOT get tag autofollowing (aka. (c) below)\n\n\n(a): The current default config, also supported for the foreseeable \nfuture (tag refspec is implicit, auto-following is enabled):\n\n [remote \"origin\"]\n url = ...\n fetch = +refs/heads/*:refs/remotes/origin/*\n\n(b): The proposed default config, using separate per-remote namespaces \nfor tags (tag refspec is explicit, auto-following is disabled):\n\n [remote \"origin\"]\n url = ...\n fetch = +refs/heads/*:refs/remotes/origin/heads/*\n fetch = +refs/tags/*:refs/remotes/origin/tags/*\n\n(c): A customized version of the proposed config, using a single global \nnamespace for tags (tag refspec is explicit, auto-following is \ndisabled):\n\n [remote \"origin\"]\n url = ...\n fetch = +refs/heads/*:refs/remotes/origin/(heads/)*\n fetch = refs/tags/*:refs/tags/*\n\n\n(Note that if we cannot reliably detect the difference between old-style \n(implicit) and new-style (explicit) remotes, we will likely have to add \na boolean flag, e.g. \"remote.origin.implicitTagFollowing\".)\n\n\n> > ... However, what I've seen at $dayjob is\n> > that more inexperienced users will often push right after\n> > committing, and at that time they're still very much in the\n> > \"working-on-one-branch\" state of mind (as opposed to the\n> > \"administering-multiple-branches\" state of mind),...\n>\n> Then \"current\" mode is a good setting for them, I would presume.\n\nArguably in some workflows, 'tracking' may be a more suitable default \n(i.e. safer for newbies) than 'current', but in practice this shouldn't \nmatter much (local branch names usually correspond to remote branch \nnames). Also, 'tracking' is more complicated when the branch originates \nlocally, and must be created on the server (\"git push -u origin \n\" vs. \"git push\"). So I agree that 'current' is the best \ndefault.\n\n\n...Johan\n\n\nOfftopic PS: Given that we're leaning towards using 'tracking' to \ndescribe the relationship between remote-tracking branches \n(refs/remotes/*) and remote branches, and 'upstream' to describe the \nrelationship between a local branch and the remote branch it \nfollows/merges (on 'git pull'), wouldn't\n\n push.default == \"upstream\"\n\nbe more descriptive than\n\n push.default == \"tracking\"\n\n?\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"161197","messageId":"7vipwlp3yv.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"201102151606.21040.johan@herland.net","subject":"Re: Re* [1.8.0] Provide proper remote ref namespaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-15T18:06:32Z","receivedAt":"2011-02-15T18:06:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> On Monday 14 February 2011, Junio C Hamano wrote:\n> ...\n> For the foreseeable future (i.e. long after v1.8.0 is out) we will still \n> have to understand and support the traditional \"tags are implicitly \n> auto-followed\" and \"tags live in a single global namespace\" concepts \n> (aka. (a) below). For new-style remotes I propose that all refspecs be \n> explicit, and that auto-follow is disabled (aka. (b) below).\n>\n> But if you try to specify a new-style remote with all tags in a single \n> global namespace, you will NOT get tag autofollowing (aka. (c) below)\n\nOk.\n\n> (Note that if we cannot reliably detect the difference between old-style \n> (implicit) and new-style (explicit) remotes, we will likely have to add \n> a boolean flag, e.g. \"remote.origin.implicitTagFollowing\".)\n\nOk.\n\n>> > ... However, what I've seen at $dayjob is\n>> > that more inexperienced users will often push right after\n>> > committing, and at that time they're still very much in the\n>> > \"working-on-one-branch\" state of mind (as opposed to the\n>> > \"administering-multiple-branches\" state of mind),...\n>>\n>> Then \"current\" mode is a good setting for them, I would presume.\n>\n> Arguably in some workflows, 'tracking' may be a more suitable default \n> (i.e. safer for newbies) than 'current', but in practice this shouldn't \n> matter much (local branch names usually correspond to remote branch \n> names).\n\nOf course you are right. The \"this pulls from there, and pushes back\nto the same place\" model was what I had in mind when I wrote the patch; \nI just was confused between the \"tracking\" vs \"current\" labels.\n\n> Offtopic PS: Given that we're leaning towards using 'tracking' to \n> describe the relationship between remote-tracking branches \n> (refs/remotes/*) and remote branches, and 'upstream' to describe the \n> relationship between a local branch and the remote branch it \n> follows/merges (on 'git pull'), wouldn't\n>\n> push.default == \"upstream\"\n>\n> be more descriptive than\n>\n> push.default == \"tracking\"\n\n\"Local Branch\" and \"Remote Tracking Branch\", both of which physically\nreside on the local end of the communication and are tied by their\n\"merge/rebase\" relationship, are much more distinct than \"Remote Branch\"\nand \"Remote Tracking Branch\" that are tied by their \"fetch\" relationship.\nA remote tracking branch is a mere (time-lagged) mirror of the remote\nbranch it tracks, and mental distance between them is much smaller than\nthat of between a local branch and its @{upstream} that is a remote\ntracking branch. Conceptually the _true_ upstream of a local branch is\nthe remote branch from which its @{upstream} remote tracking branch copies\nfrom.\n\nSo in that sense, I agree \"pushing my change to the upstream\" would match\nthe mental model of an end user somewhat better than \"pushing my change\nback to what I track\".\n\nPerhaps leave \"tracking\" as a deprecated synonym and add \"upstream\" as the\nofficial name of the mode?\n"},{"id":"161245","messageId":"201102160154.24744.johan@herland.net","threadId":"26377","inReplyTo":"7vipwlp3yv.fsf@alter.siamese.dyndns.org","subject":"[PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-02-16T00:54:24Z","receivedAt":"2011-02-16T00:54:24Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"Users are sometimes confused with two different types of \"tracking\" behavior\nin Git: \"remote-tracking\" branches (e.g. refs/remotes/*/*) versus the\nmerge/rebase relationship between a local branch and its @{upstream}\n(controlled by branch.foo.remote and branch.foo.merge config settings).\n\nWhen the push.default is set to 'tracking', it specifies that a branch should\nbe pushed to its @{upstream} branch. In other words, setting push.default to\n'tracking' applies only to the latter of the above two types of \"tracking\"\nbehavior.\n\nIn order to make this more understandable to the user, we rename the\npush.default == 'tracking' option to push.default == 'upstream'.\n\npush.default == 'tracking' is left as a deprecated synonym for 'upstream'.\n\nSigned-off-by: Johan Herland \n---\n\nOn Tuesday 15 February 2011, Junio C Hamano wrote:\n> Perhaps leave \"tracking\" as a deprecated synonym and add \"upstream\" as\n> the official name of the mode?\n\nThis patch does just that.\n\nI took the liberty of renaming the setup_push_tracking() function as\nwell, and rephrasing its error messages. Although this may be\nconsidered code churn, I think it's worth keeping the function naming\ncloser to the phrasing in the documentation.\n\n\nHave fun! :)\n\n...Johan\n\n\n Documentation/config.txt | 3 ++-\n builtin/push.c | 10 +++++-----\n cache.h | 2 +-\n config.c | 6 ++++--\n 4 files changed, 12 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex c5e1835..c995a1a 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1591,7 +1591,8 @@ push.default::\n * `matching` - push all matching branches.\n All branches having the same name in both ends are considered to be\n matching. This is the default.\n-* `tracking` - push the current branch to its upstream branch.\n+* `upstream` - push the current branch to its upstream branch.\n+* `tracking` - deprecated synonym for `upstream`.\n * `current` - push the current branch to a branch of the same name.\n \n rebase.stat::\ndiff --git a/builtin/push.c b/builtin/push.c\nindex e655eb7..31da418 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -64,17 +64,17 @@ static void set_refspecs(const char **refs, int nr)\n \t}\n }\n \n-static void setup_push_tracking(void)\n+static void setup_push_upstream(void)\n {\n \tstruct strbuf refspec = STRBUF_INIT;\n \tstruct branch *branch = branch_get(NULL);\n \tif (!branch)\n \t\tdie(\"You are not currently on a branch.\");\n \tif (!branch->merge_nr || !branch->merge)\n-\t\tdie(\"The current branch %s is not tracking anything.\",\n+\t\tdie(\"The current branch %s has no upstream branch.\",\n \t\t branch->name);\n \tif (branch->merge_nr != 1)\n-\t\tdie(\"The current branch %s is tracking multiple branches, \"\n+\t\tdie(\"The current branch %s has multiple upstream branches, \"\n \t\t \"refusing to push.\", branch->name);\n \tstrbuf_addf(&refspec, \"%s:%s\", branch->name, branch->merge[0]->src);\n \tadd_refspec(refspec.buf);\n@@ -88,8 +88,8 @@ static void setup_default_push_refspecs(void)\n \t\tadd_refspec(\":\");\n \t\tbreak;\n \n-\tcase PUSH_DEFAULT_TRACKING:\n-\t\tsetup_push_tracking();\n+\tcase PUSH_DEFAULT_UPSTREAM:\n+\t\tsetup_push_upstream();\n \t\tbreak;\n \n \tcase PUSH_DEFAULT_CURRENT:\ndiff --git a/cache.h b/cache.h\nindex d83d68c..7acf120 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -608,7 +608,7 @@ enum rebase_setup_type {\n enum push_default_type {\n \tPUSH_DEFAULT_NOTHING = 0,\n \tPUSH_DEFAULT_MATCHING,\n-\tPUSH_DEFAULT_TRACKING,\n+\tPUSH_DEFAULT_UPSTREAM,\n \tPUSH_DEFAULT_CURRENT\n };\n \ndiff --git a/config.c b/config.c\nindex 625e051..9184900 100644\n--- a/config.c\n+++ b/config.c\n@@ -737,8 +737,10 @@ static int git_default_push_config(const char *var, const char *value)\n \t\t\tpush_default = PUSH_DEFAULT_NOTHING;\n \t\telse if (!strcmp(value, \"matching\"))\n \t\t\tpush_default = PUSH_DEFAULT_MATCHING;\n-\t\telse if (!strcmp(value, \"tracking\"))\n-\t\t\tpush_default = PUSH_DEFAULT_TRACKING;\n+\t\telse if (!strcmp(value, \"upstream\"))\n+\t\t\tpush_default = PUSH_DEFAULT_UPSTREAM;\n+\t\telse if (!strcmp(value, \"tracking\")) /* deprecated */\n+\t\t\tpush_default = PUSH_DEFAULT_UPSTREAM;\n \t\telse if (!strcmp(value, \"current\"))\n \t\t\tpush_default = PUSH_DEFAULT_CURRENT;\n \t\telse {\n-- \n1.7.4\n"},{"id":"161261","messageId":"7vd3mslc5z.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"201102160154.24744.johan@herland.net","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-16T06:35:20Z","receivedAt":"2011-02-16T06:35:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> I took the liberty of renaming the setup_push_tracking() function as\n> well, and rephrasing its error messages. Although this may be\n> considered code churn, I think it's worth keeping the function naming\n> closer to the phrasing in the documentation.\n\nI don't have any problem with that kind of internal naming clean-up,\nespecially when there is no other change in flight that would interfere or\ncause conflict with it.\n\nWill hold for a few days to see if we see any reasonable objection, and\nthen queue if not. Thanks.\n"},{"id":"161269","messageId":"vpqy65gs6hs.fsf@bauges.imag.fr","threadId":"26377","inReplyTo":"201102160154.24744.johan@herland.net","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-16T08:55:59Z","receivedAt":"2011-02-16T08:55:59Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johan Herland writes:\n\n> In order to make this more understandable to the user, we rename the\n> push.default == 'tracking' option to push.default == 'upstream'.\n\nWhile we're there, shouldn't we also rename 'branch..merge' to\n'branch..upstream'?\n\nIt has a bit more consequences, since external porcelains/scripts are\nlikely to call \"git config branch.foo.merge\", and would be broken by\nsuch change. But maybe 1.8.0 is the time for this kind of things.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"161275","messageId":"alpine.DEB.2.00.1102160421300.14950@debian","threadId":"26377","inReplyTo":"vpqy65gs6hs.fsf@bauges.imag.fr","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-02-16T09:42:56Z","receivedAt":"2011-02-16T09:42:56Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Wed, 16 Feb 2011, Matthieu Moy wrote:\n\n> Johan Herland writes:\n> \n> > In order to make this more understandable to the user, we rename the\n> > push.default == 'tracking' option to push.default == 'upstream'.\n> \n> While we're there, shouldn't we also rename 'branch..merge' to\n> 'branch..upstream'?\n\nI have a draft proposal not exactly to rename it, but to replace it by\na new branch..upstream which would point to local ref rather\nthan a ref on the remote, so one would have e.g.\nbranch.topic.upstream = refs/remotes/origin/master. Maybe I should\nclean up that proposal and send it soon. The topic comes up quite\nfrequently.\n\nMy biggest concern with it is that it breaks the use case where the\nremote is not named, i.e. where one has a configuration that looks\nlike:\n\n[branch \"topic\"]\n\tremote = git://git.kernel.org/pub/scm/git/git.git\n\tmerge = master\n\nI don't know how common that case is, so I don't know if it would it\nbe acceptable to break it. I would of course not suggest no longer\nfall back to reading branch..(remote+merge), but at some point\nwe would drop support for that and then we would disallow that use\ncase.\n\nI'm also not sure the benefits are that great; this is just one of\nthose things I think \"we should do differently if designing git from\nscratch\".\n\nWhat do you think? Should I even bother sending a formal proposal?\n\n\n/Martin\n"},{"id":"161280","messageId":"201102161108.26637.jnareb@gmail.com","threadId":"26377","inReplyTo":"alpine.DEB.2.00.1102160421300.14950@debian","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-16T10:08:22Z","receivedAt":"2011-02-16T10:08:22Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia środa 16. lutego 2011 10:42, Martin von Zweigbergk napisał:\n> On Wed, 16 Feb 2011, Matthieu Moy wrote:\n> \n> > Johan Herland writes:\n> > \n> > > In order to make this more understandable to the user, we rename the\n> > > push.default == 'tracking' option to push.default == 'upstream'.\n> > \n> > While we're there, shouldn't we also rename 'branch..merge' to\n> > 'branch..upstream'?\n> \n> I have a draft proposal not exactly to rename it, but to replace it by\n> a new branch..upstream which would point to local ref rather\n> than a ref on the remote, so one would have e.g.\n> branch.topic.upstream = refs/remotes/origin/master. Maybe I should\n> clean up that proposal and send it soon. The topic comes up quite\n> frequently.\n\nActually while I think that it makes more sense to use local ref for\n'branch..merge' because it is what is merged, i.e.:\n\n branch.topic.merge = refs/remotes/origin/master\n\nor in case of tracking local branch\n\n branch.topic.remote = .\n branch.topic.merge = refs/heads/master\n\nI think that for 'branch..upstream' it would make more sense to\nuse the name that *upstream* uses, i.e.\n\n branch.topic.upstream = refs/heads/master\n\n-- \nJakub Narebski\nPoland\n"},{"id":"161284","messageId":"vpqhbc4mg1c.fsf@bauges.imag.fr","threadId":"26377","inReplyTo":"201102161108.26637.jnareb@gmail.com","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-16T10:26:23Z","receivedAt":"2011-02-16T10:26:23Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jakub Narebski writes:\n\n> Actually while I think that it makes more sense to use local ref for\n> 'branch..merge' because it is what is merged, i.e.:\n>\n> branch.topic.merge = refs/remotes/origin/master\n[...]\n> I think that for 'branch..upstream' it would make more sense to\n> use the name that *upstream* uses, i.e.\n>\n> branch.topic.upstream = refs/heads/master\n\nI disagree. Both --set-upstream and @{upstream} both refer to\nrefs/remotes/origin/master, i.e. the remote-tracking name in the local\nrepository, not to the local name in the remote repository.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"161285","messageId":"AANLkTikq67jQnM555nHKeyk5t0Ln+Hp97WSztTaej_CW@mail.gmail.com","threadId":"26377","inReplyTo":"vpqhbc4mg1c.fsf@bauges.imag.fr","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-16T10:27:47Z","receivedAt":"2011-02-16T10:27:47Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Feb 16, 2011 at 10:26, Matthieu Moy\n wrote:\n>> I think that for 'branch..upstream' it would make more sense to\n\nI like the idea of naming it 'upstream', although I don't care much\neither way for restricting what you specify. I've always thought\n'merge' was a curious name that didn't really fit with my mental model\nof what I was configuring.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"161294","messageId":"20110216105427.GA27909@pcpool00.mathematik.uni-freiburg.de","threadId":"26377","inReplyTo":"alpine.DEB.2.00.1102160421300.14950@debian","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Bernhard R. Link","fromEmail":"brl+ccmadness@pcpool00.mathematik.uni-freiburg.de","sentAt":"2011-02-16T10:54:27Z","receivedAt":"2011-02-16T10:54:27Z","isPatch":true,"sender":{"key":"brl+ccmadness@pcpool00.mathematik.uni-freiburg.de","avatar":null},"body":"* Martin von Zweigbergk [110216 10:43]:\n> On Wed, 16 Feb 2011, Matthieu Moy wrote:\n>\n> > Johan Herland writes:\n> >\n> > > In order to make this more understandable to the user, we rename the\n> > > push.default == 'tracking' option to push.default == 'upstream'.\n> >\n> > While we're there, shouldn't we also rename 'branch..merge' to\n> > 'branch..upstream'?\n>\n> I have a draft proposal not exactly to rename it, but to replace it by\n> a new branch..upstream which would point to local ref rather\n> than a ref on the remote, so one would have e.g.\n> branch.topic.upstream = refs/remotes/origin/master.\n\nMaking it name a local ref name would also make it easier to add support\nfor listing multiple references.\n\nThe use case I miss support for (please hint me if this is already\npossible somehow), is having multiple remotes where other people (or\nmore importantly I at other computers for projects without central\nrepository) add commits.\n\nCurrently one needs to fetch all the remotes and then manually do a\nmerge remote1/branchname remote2/branchname remote3/branchname and so\non. It would be nice if a single git pull could do that.\n\n\tBernhard R. Link\n"},{"id":"161316","messageId":"7v8vxflv7p.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"AANLkTikq67jQnM555nHKeyk5t0Ln+Hp97WSztTaej_CW@mail.gmail.com","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-16T17:56:10Z","receivedAt":"2011-02-16T17:56:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> On Wed, Feb 16, 2011 at 10:26, Matthieu Moy\n> wrote:\n>>> I think that for 'branch..upstream' it would make more sense to\n>\n> I like the idea of naming it 'upstream', although I don't care much\n> either way for restricting what you specify. I've always thought\n> 'merge' was a curious name that didn't really fit with my mental model\n> of what I was configuring.\n\nThat pretty much comes from the days back when 'merge' was the only method\nof integrating with what the other party did. \n\nI agree \"upstream\" is a better name. The name \"merge\" is about what\noperation uses it, and does not say why it is used (i.e. \"we merge with it\nbecause it is _the other end_ of the integration\"); the latter is a more\nimportant thing to express.\n\nUntil another method of integration (namely, rebase) started using the\nsame mechanism, this was Ok, but when it happend, the name \"merge\"\nimmediately stopped making sense, but we did not rename nor give a synonym\nto the variable.\n\nThe name \"upstream\" prepares us for yet another method of integration that\nnobody has invented yet.\n\nAs to its value being what the other end calls the source, I think it is\nnot a good idea to change it, and it is even a worse idea to add a new\nconfiguration variable that points into the tracking branches on our side.\n@{upstream} is a short-hand notation to call the tracking branch of the\n\"upstream\" we have been discussing, and has to point at refs/remotes/\nhierarchy, but the entire point of the notation is that the users do not\nhave to see/type \"refs/remotes/\" when they say\n\n $ git merge @{upstream}\n\nbut at the level of an end-user's world-view, his branch that was forked\nfrom origin's \"master\" integrates with origin's \"master\", and the use of\nan intermediary, the refs/remotes/origin/master remote tracking branch\nthat is kept on the local side, is a mere implementation detail.\n\nIOW, I consider --set-upstream that takes refs/remotes without bothering\nto go through the remotes..fetch mapping is a design bug (it may\nhave come from sloppy initial coding---it certainly is easier to store\nwhat you get without computing anything). That may be something we might\nwant to fix in 1.8.0.\n"},{"id":"161318","messageId":"AANLkTim9zxsQVMXuuccNH-g=Ueiau=Hp8dJto2Sbw-8U@mail.gmail.com","threadId":"26377","inReplyTo":"7v8vxflv7p.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-16T18:08:31Z","receivedAt":"2011-02-16T18:08:31Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Feb 16, 2011 at 17:56, Junio C Hamano wrote:\n> That pretty much comes from the days back when 'merge' was the only method\n> of integrating with what the other party did.\n\n\n\nCool, thanks for the history.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"161319","messageId":"7vy65fkeqx.fsf@alter.siamese.dyndns.org","threadId":"26377","inReplyTo":"7v8vxflv7p.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-16T18:37:10Z","receivedAt":"2011-02-16T18:37:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> IOW, I consider --set-upstream that takes refs/remotes without bothering\n> to go through the remotes..fetch mapping is a design bug (it may\n> have come from sloppy initial coding---it certainly is easier to store\n> what you get without computing anything). That may be something we might\n> want to fix in 1.8.0.\n\nPlease scratch this paragraph; this was a sloppy thinking on my part.\nThe option, and its cousin --track, do call into setup_tracking() to look\nup the mapping.\n\nThe --set-upstream option needs to set both which remote's what branch,\nand refs/remotes/origin/master is a way to say \"origin's master\" and it\nwas inevitable to expose refs/remotes/ to the UI level if you wanted to\nimplement it as an option with a single argument. So in that sense there\nis nothing to fix.\n\nConceptually, \"git branch --set-upstream=master --set-remote=origin\" is\nwhat it really wants to say, even though that is probably longer to type.\nThere still might be a room for UI improvement.\n"},{"id":"161480","messageId":"alpine.DEB.2.00.1102171947230.14950@debian","threadId":"26377","inReplyTo":"7v8vxflv7p.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-02-18T00:51:05Z","receivedAt":"2011-02-18T00:51:05Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Wed, 16 Feb 2011, Junio C Hamano wrote:\n\n> As to its value being what the other end calls the source, I think it is\n> not a good idea to change it, and it is even a worse idea to add a new\n> configuration variable that points into the tracking branches on our side.\n> @{upstream} is a short-hand notation to call the tracking branch of the\n> \"upstream\" we have been discussing, and has to point at refs/remotes/\n> hierarchy, but the entire point of the notation is that the users do not\n> have to see/type \"refs/remotes/\" when they say\n> \n> $ git merge @{upstream}\n> \n> but at the level of an end-user's world-view, his branch that was forked\n> from origin's \"master\" integrates with origin's \"master\", and the use of\n> an intermediary, the refs/remotes/origin/master remote tracking branch\n> that is kept on the local side, is a mere implementation detail.\n"},{"id":"161482","messageId":"alpine.DEB.2.00.1102171951240.14950@debian","threadId":"26377","inReplyTo":"alpine.DEB.2.00.1102171947230.14950@debian","subject":"Re: [PATCH] push.default: Rename 'tracking' to 'upstream'","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-02-18T00:57:10Z","receivedAt":"2011-02-18T00:57:10Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, 17 Feb 2011, Martin von Zweigbergk wrote:\n\nSorry, sent by mistake (wrong key).\n\n> On Wed, 16 Feb 2011, Junio C Hamano wrote:\n> \n> > As to its value being what the other end calls the source, I think it is\n> > not a good idea to change it, and it is even a worse idea to add a new\n> > configuration variable that points into the tracking branches on our side.\n> > @{upstream} is a short-hand notation to call the tracking branch of the\n> > \"upstream\" we have been discussing, and has to point at refs/remotes/\n> > hierarchy, but the entire point of the notation is that the users do not\n> > have to see/type \"refs/remotes/\" when they say\n> > \n> > $ git merge @{upstream}\n\nWhat I meant to say was that I'm not sure I agree that the point of\nthe @{upstream} notation is to hide the refs/remotes hierarchy. At\nleast to me. I think more important is having a single way to refer to\nthe upstream, whatever its value may be.\n\n> > \n> > but at the level of an end-user's world-view, his branch that was forked\n> > from origin's \"master\" integrates with origin's \"master\", and the use of\n> > an intermediary, the refs/remotes/origin/master remote tracking branch\n> > that is kept on the local side, is a mere implementation detail.\n\nAnyway, I agree with with this part. And I'm happy Johan adding the\n\"upstream\" alias.\n\n\n/Martin\n"}]}