* [1.8.0] Remote tag namespace
@ 2011-02-01 10:44 Nguyen Thai Ngoc Duy
2011-02-01 14:10 ` Leo Razoumov
` (2 more replies)
0 siblings, 3 replies; 104+ messages in thread
From: Nguyen Thai Ngoc Duy @ 2011-02-01 10:44 UTC (permalink / raw)
To: Git Mailing List; +Cc: Nicolas Pitre
On Tue, Feb 1, 2011 at 11:16 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote:
>> Another random wish, which does not come with a proposal. How about
>> tag namespace (ie. tags from a remote stay in remote namespace)?
>
> Please make this into a proper proposal. this would be indeed a huge
> improvement.
OK I'm not familiar with tag code, but I can try.
Proposal:
Reserve refs/remote-tags namespace to store tags from remotes. Its
structure is the same as in refs/remotes. When pulling tags, put them
in refs/remote-tags/<remote> instead of refs/tags.
Tag dereference code will be taught about refs/remote-tags with
similar deref order as in remote branches.
Config branch.*.globalTags (perhaps takes a pattern?) may be defined
to create refs/tags/* in addition to refs/remote-tags/<remote>/* when
fetching tags.
Migration plan:
refs/remote-tags will be used to store new tags unconditionally, which
means there will be duplicates with the already-fetched tags in global
namespace. Perhaps we can check if they point to the same sha-1, then
choose not to annoy users with ambiguous tag messages?
I suggest to add config compatibility.remoteTagNamespace, default to
false, which retains current behavior (i.e. also create tags in global
namespace in addition to refs/remote-tags). After 1.8.0 (or a few more
cycles) the default value becomes true. Users who wish to keep old
behavior can put "false" in their ~/.gitconfig.
After a few years, remove support for the config key. Unrecognized
compatibility.* keys will abort program. Users are forced to new
behavior. I don't know, we may want to start annoy users that have the
config key set a few cycles before we drop support.
--
Duy
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Remote tag namespace 2011-02-01 10:44 [1.8.0] Remote tag namespace Nguyen Thai Ngoc Duy @ 2011-02-01 14:10 ` Leo Razoumov 2011-02-01 15:07 ` Marc Branchaud 2011-02-01 18:14 ` Jeff King 2 siblings, 0 replies; 104+ messages in thread From: Leo Razoumov @ 2011-02-01 14:10 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Nicolas Pitre On Tue, Feb 1, 2011 at 05:44, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote: > On Tue, Feb 1, 2011 at 11:16 AM, Nicolas Pitre <nico@fluxnic.net> wrote: >> On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote: >>> Another random wish, which does not come with a proposal. How about >>> tag namespace (ie. tags from a remote stay in remote namespace)? >> >> Please make this into a proper proposal. this would be indeed a huge >> improvement. > > OK I'm not familiar with tag code, but I can try. > > Proposal: > Remote tag namespace is a great feature long overdue in git. Due to git's current flat tag namespace I am forced to make my tags artificially long like "my_project_repo_name/v-1.2.3". Looking forward to remote tag namespace -- sooner the better! --Leo-- ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Remote tag namespace 2011-02-01 10:44 [1.8.0] Remote tag namespace Nguyen Thai Ngoc Duy 2011-02-01 14:10 ` Leo Razoumov @ 2011-02-01 15:07 ` Marc Branchaud 2011-02-01 15:35 ` Nguyen Thai Ngoc Duy 2011-02-01 18:14 ` Jeff King 2 siblings, 1 reply; 104+ messages in thread From: Marc Branchaud @ 2011-02-01 15:07 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Nicolas Pitre On 11-02-01 05:44 AM, Nguyen Thai Ngoc Duy wrote: > On Tue, Feb 1, 2011 at 11:16 AM, Nicolas Pitre <nico@fluxnic.net> wrote: >> On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote: >>> Another random wish, which does not come with a proposal. How about >>> tag namespace (ie. tags from a remote stay in remote namespace)? >> >> Please make this into a proper proposal. this would be indeed a huge >> improvement. > > OK I'm not familiar with tag code, but I can try. OK, that teaches me to read through _all_ the unread messages before posting! Needless to say, I support this proposal. > Proposal: > > Reserve refs/remote-tags namespace to store tags from remotes. Its > structure is the same as in refs/remotes. When pulling tags, put them > in refs/remote-tags/<remote> instead of refs/tags. > Tag dereference code will be taught about refs/remote-tags with > similar deref order as in remote branches. I suggested a different home for the tags, but I don't have any insight into what makes the most sense. I'll defer to wiser folk on this. > Config branch.*.globalTags (perhaps takes a pattern?) may be defined > to create refs/tags/* in addition to refs/remote-tags/<remote>/* when > fetching tags. I may be getting into the weeds prematurely here, but why put the config item under branch.* ? Or did you mean remote.*.globalTags? Personally, I don't see a need for this. I'd rather have the rev-parse machinery search in remote tag namespaces if it can't find anything local. > Migration plan: > > refs/remote-tags will be used to store new tags unconditionally, which > means there will be duplicates with the already-fetched tags in global > namespace. Perhaps we can check if they point to the same sha-1, then > choose not to annoy users with ambiguous tag messages? (Again with the weeds...) I don't think we could do that. I'd want to be able to have my own (local) tags that refer to the same commits as one or more remote tags, and I'd want to see them all. Better for "git tag" to learn scoping options like "git branch": -a and -r. (Hmm, maybe git-tag's current -a could become -A...) > I suggest to add config compatibility.remoteTagNamespace, default to > false, which retains current behavior (i.e. also create tags in global > namespace in addition to refs/remote-tags). After 1.8.0 (or a few more > cycles) the default value becomes true. Users who wish to keep old > behavior can put "false" in their ~/.gitconfig. > > After a few years, remove support for the config key. Unrecognized > compatibility.* keys will abort program. Users are forced to new > behavior. I don't know, we may want to start annoy users that have the > config key set a few cycles before we drop support. Sounds good. I'd vote for a faster transition, but that's just me. :) M. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Remote tag namespace 2011-02-01 15:07 ` Marc Branchaud @ 2011-02-01 15:35 ` Nguyen Thai Ngoc Duy 2011-02-02 19:38 ` Marc Branchaud 0 siblings, 1 reply; 104+ messages in thread From: Nguyen Thai Ngoc Duy @ 2011-02-01 15:35 UTC (permalink / raw) To: Marc Branchaud; +Cc: Git Mailing List, Nicolas Pitre On Tue, Feb 1, 2011 at 10:07 PM, Marc Branchaud <marcnarc@xiplink.com> wrote: >> Config branch.*.globalTags (perhaps takes a pattern?) may be defined >> to create refs/tags/* in addition to refs/remote-tags/<remote>/* when >> fetching tags. > > I may be getting into the weeds prematurely here, but why put the config item > under branch.* ? Or did you mean remote.*.globalTags? Personally, I don't > see a need for this. I'd rather have the rev-parse machinery search in > remote tag namespaces if it can't find anything local. Ahh.. yeah it's remote.*.globalTags. I don't know, some people might find current behavior useful. So instead of dropping it entirely, I'd limit it to certain remotes. > >> Migration plan: >> >> refs/remote-tags will be used to store new tags unconditionally, which >> means there will be duplicates with the already-fetched tags in global >> namespace. Perhaps we can check if they point to the same sha-1, then >> choose not to annoy users with ambiguous tag messages? > > (Again with the weeds...) I don't think we could do that. I'd want to be > able to have my own (local) tags that refer to the same commits as one or > more remote tags, and I'd want to see them all. For listing tags (I forgot this) I think we just follow how git-branch does it: show only local tags unless -r (or some other option) is given. What I meant in the above paragraph is "some-ref" can refer to refs/tags/some-ref or refs/remotes/foo/tags/some-ref, but I was wrong on this. The latter can only be referred by foo/some-ref or with migration support in your proposal. > > Better for "git tag" to learn scoping options like "git branch": -a and -r. > (Hmm, maybe git-tag's current -a could become -A...) When tags are put in remote namespace (wherever it actually is), git-tag must learn -r like git-branch. I think option name change for -a is too late though. When "git-ng" rewrite project comes (that is after libgit2 replaces git core), we may have everything consistent again. PS. I bet git-ng would start after Wine 2.0 is released. -- Duy ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Remote tag namespace 2011-02-01 15:35 ` Nguyen Thai Ngoc Duy @ 2011-02-02 19:38 ` Marc Branchaud 0 siblings, 0 replies; 104+ messages in thread From: Marc Branchaud @ 2011-02-02 19:38 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Nicolas Pitre On 11-02-01 10:35 AM, Nguyen Thai Ngoc Duy wrote: > On Tue, Feb 1, 2011 at 10:07 PM, Marc Branchaud<marcnarc@xiplink.com> wrote: >>> Config branch.*.globalTags (perhaps takes a pattern?) may be defined >>> to create refs/tags/* in addition to refs/remote-tags/<remote>/* when >>> fetching tags. >> >> I may be getting into the weeds prematurely here, but why put the config item >> under branch.* ? Or did you mean remote.*.globalTags? Personally, I don't >> see a need for this. I'd rather have the rev-parse machinery search in >> remote tag namespaces if it can't find anything local. > > Ahh.. yeah it's remote.*.globalTags. I don't know, some people might > find current behavior useful. So instead of dropping it entirely, I'd > limit it to certain remotes. IMHO, it's best not to assume what people might want. Better to wait for someone to ask for something specific. [ ...snip... ] > When tags are put in remote namespace (wherever it actually is), > git-tag must learn -r like git-branch. I think option name change for > -a is too late though. When "git-ng" rewrite project comes (that is > after libgit2 replaces git core), we may have everything consistent > again. I think we could start by making "git tag -A" a synonym for "git tag -a" with a verbose warning when "-a" is used that it'll soon gain a different meaning. Also, during the transition "git tag -a" without any other options could (without the big warning) list all local and remote tags (like "git branch -a") and if someone wanted to make an annotated tag of the current tip they could do "git tag -A" or "git tag -a HEAD". M. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Remote tag namespace 2011-02-01 10:44 [1.8.0] Remote tag namespace Nguyen Thai Ngoc Duy 2011-02-01 14:10 ` Leo Razoumov 2011-02-01 15:07 ` Marc Branchaud @ 2011-02-01 18:14 ` Jeff King 2011-02-01 23:14 ` Sverre Rabbelier 2011-02-01 23:15 ` [1.8.0] Remote tag namespace Johan Herland 2 siblings, 2 replies; 104+ messages in thread From: Jeff King @ 2011-02-01 18:14 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Nicolas Pitre On Tue, Feb 01, 2011 at 05:44:50PM +0700, Nguyen Thai Ngoc Duy wrote: > OK I'm not familiar with tag code, but I can try. > > Proposal: > > Reserve refs/remote-tags namespace to store tags from remotes. Its > structure is the same as in refs/remotes. When pulling tags, put them > in refs/remote-tags/<remote> instead of refs/tags. > Tag dereference code will be taught about refs/remote-tags with > similar deref order as in remote branches. There are similar questions around remote notes refs. Should there also be a refs/remote-notes? And there was some discussion recently about fetching remote replace refs. Should we perhaps be massaging refs/remotes into a structure to handle all of these things? Like: refs/remotes/origin/HEAD (-> refs/remotes/origin/heads/master) refs/remotes/origin/heads/master refs/remotes/origin/tags/v1.7.4 refs/remotes/origin/notes/commit refs/remotes/origin/replace/f67e92af477a2255b64a1ece33d9d126e763fe9b i.e., make refs/remotes/* an actual mirror of selected parts of the remote's refs/ hierarchy. And then figure out sane rules for merging those namespaces into the ref lookup procedure. For heads and tags, probably some tweaking of the lookup rules in dwim_ref; for replacements, probably you would want to manually say "I am interested in this replace" and copy or symref-link it into your refs/ hierarchy. And probably something similar with notes. Obviously I haven't thought it all the way through, but it just seems a shame not to deal with other similar issues when looking at tags. -Peff ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Remote tag namespace 2011-02-01 18:14 ` Jeff King @ 2011-02-01 23:14 ` Sverre Rabbelier 2011-02-02 2:21 ` [1.8.0] Provide proper remote ref namespaces Johan Herland 2011-02-01 23:15 ` [1.8.0] Remote tag namespace Johan Herland 1 sibling, 1 reply; 104+ messages in thread From: Sverre Rabbelier @ 2011-02-01 23:14 UTC (permalink / raw) To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, Git Mailing List, Nicolas Pitre Heya, On Tue, Feb 1, 2011 at 19:14, Jeff King <peff@peff.net> wrote: > i.e., make refs/remotes/* an actual mirror of selected parts of the > remote's refs/ hierarchy. And then figure out sane rules for merging > those namespaces into the ref lookup procedure. Jeff, Nguy, are either of you interested in writing up a new/modifying this proposal to be about namespacing everything? I think it definitely makes sense to have a namespace for notes, replaces, as well as tags, especially since it would also allow us to propagate these by default (at least to the refs/remotes namespace), and think it's a good idea to go all the way if we're going to do this at all (or we'll have the same discussion again later for notes and replaces, and whatever comes after that). -- Cheers, Sverre Rabbelier ^ permalink raw reply [flat|nested] 104+ messages in thread
* [1.8.0] Provide proper remote ref namespaces 2011-02-01 23:14 ` Sverre Rabbelier @ 2011-02-02 2:21 ` Johan Herland 2011-02-02 13:27 ` Santi Béjar ` (3 more replies) 0 siblings, 4 replies; 104+ messages in thread From: Johan Herland @ 2011-02-02 2:21 UTC (permalink / raw) To: git; +Cc: Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Wednesday 02 February 2011, Sverre Rabbelier wrote: > On Tue, Feb 1, 2011 at 19:14, Jeff King <peff@peff.net> wrote: > > i.e., make refs/remotes/* an actual mirror of selected parts of the > > remote's refs/ hierarchy. And then figure out sane rules for merging > > those namespaces into the ref lookup procedure. > > Jeff, Nguy, are either of you interested in writing up a new/modifying > this proposal to be about namespacing everything? Here's my go at phrasing this in a proposal format. Feel free to revise and resend: Proposal: Currently, git stores remote refs in the local repo by default as follows: Remote repo -> Local repo --------------------------------------------------------- HEAD refs/remotes/$remote/HEAD (implicit) refs/heads/* refs/remotes/$remote/* refs/tags/* refs/tags/* (implicit, autofollow) refs/replace/* (TBD) refs/notes/* (TBD) Several users report that they are confused by the difference in how heads and tags are mapped, and by the implicit mappings that are not mentioned in the configured refspecs. Also, as users want to share ever more different types of refs (replace refs and notes refs have been discussed recently), the existing ref mappings (aka. refspecs) do not suggest a natural/intuitive mapping for the new ref types. Instead, we should change the default ref mappings into the following: Remote repo -> Local repo -------------------------------------------------- HEAD refs/remotes/$remote/HEAD refs/heads/* refs/remotes/$remote/heads/* refs/tags/* refs/remotes/$remote/tags/* refs/replace/* refs/remotes/$remote/replace/* refs/notes/* refs/remotes/$remote/notes/* In short, we make refs/remotes/$remote/* an actual mirror of selected parts of the remote's refs/* hierarchy. This provides consistent namespaces for remote refs that naturally allows adding new ref types in the future. This change obviously affects our ref-handling code: - Remote tags are now stored separate from local tags. When looking up a shorthand tag name (e.g. v1.7.4), we should consult local tags (refs/tags/v1.7.4) before remote tags (refs/remotes/*/tags/v1.7.4 [1]). See [2] for more details. - Remote heads have moved into refs/remotes/$remote/heads/*, hence invalidating shorthand remote head names, like "origin/master". We should change the lookup code, so that a shorthand ref of the form "$remote/$head" where "$remote" happens to match a configured remote is eventually expanded into lookup for "refs/remotes/$remote/heads/$head" [3]. - We might want to generalize the handling of "$remote/$head" into allowing shorthands like "$remote/$tag", "$remote/$replace" and "$remote/$note" as well (provided, of course, that they match unambiguously). - All fetch refspecs should be given explicitly. Sub-proposal: While we are changing the default refspecs, we should also consider whether we want to keep the auto-following behavior that Git currently does for tags (don't fetch tags that refer to objects not otherwise fetched by another refspec). If we simply make an explicit "+refs/tags/*:refs/remotes/$remote/tags/*" refspec, we will lose the auto- following behavior. If we do want to keep the auto-following behavior, we could for example add a "~" prefix to the refspec to trigger auto-following behavior (i.e. this refspec only applies to refs that happen to point at objects fetched by way of a different refspec). See http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160795 for more details. Risks: Existing scripts/programs may make assumptions about the layout of remote refs without consulting the configured refspecs. However, such scripts/programs may also break today when non-default refspecs are used. When remotes have conflicting tags (same tag name points to different objects), and the tag name does not exist locally (in refs/tags/*), looking up the shorthand tag name will result in an "ambiguous ref" error (instead of silently adopting whichever tag was fetched first). Although many consider this an improvement on the current behavior, there may be scenarios where this causes problems in external scripts/programs. Existing scripts/programs that assume and depend on the current implicit refspecs (or the tag auto-following behavior), might encounter problems when we drop these in favor of explicit refspecs. Migration plan: The main part of this proposal is simply changing the default refspecs. As such, the proposal can be simulated in current Git versions by setting up custom refspecs according to the above table of ref mappings. In v1.8.0, we should default to the new default refspecs when creating new remotes. However, existing remotes (created pre-v1.8.0) must continue to work as before, so we cannot simply remove the implicit refspecs (or tag auto-following). Instead we need to make sure that the implicit refspecs is NOT applied to the new-style remotes. Identifying new-style vs. old-style remotes can be done by looking at the refspec itself (old-style: "refs/remotes/$remote/*", new-style: "refs/remotes/$remote/heads/*"), or (worst case) by introducing a config variable specifying the desired behavior (defaulting to old-style). When adding the new rules for looking up shorthand refs (described above), we should carefully verify that these won't cause regressions when applied to old-style refspecs in existing repos. In a later major version we can consider removing the (by then ancient) implicit refspecs, and any other outdated compatibility measures code in our ref lookup code. Have fun! :) ...Johan [1]: The "refs/remotes/*/tags/v1.7.4" is not hardcoded, but rather the (default) result of mapping "refs/tags/v1.7.4" through each remote's refspecs as defined in the config. [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local tag (refs/tags/v1.7.4) is found, then we have an unambiguous match. If no local tag is found, we look up the tag name in all configured remotes (using the method described in [1]). If the tag name exists in one or more remotes, and those remotes all agree on its ultimate object name (after applying e.g. ^{commit} or whatever is appropriate in the context of the lookup), then we also have an unambiguous match. However, if the tag name exists in multiple remotes, and they do NOT all agree on its ultimate object name, then the shorthand tag name is ambiguous and the lookup fails. The user can always resolve this ambiguity by creating a local tag (refs/tags/v1.7.4) pointing to the desired object. [3]: As in [1], the "refs/remotes/$remote/heads/$head" is not hardcoded, but rather the result of mapping "refs/heads/$head" through the refspecs for $remote as defined in the config. -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-02 2:21 ` [1.8.0] Provide proper remote ref namespaces Johan Herland @ 2011-02-02 13:27 ` Santi Béjar 2011-02-02 15:51 ` Johan Herland 2011-02-03 5:33 ` Nguyen Thai Ngoc Duy ` (2 subsequent siblings) 3 siblings, 1 reply; 104+ messages in thread From: Santi Béjar @ 2011-02-02 13:27 UTC (permalink / raw) To: Johan Herland Cc: git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Wed, Feb 2, 2011 at 3:21 AM, Johan Herland <johan@herland.net> wrote: > On Wednesday 02 February 2011, Sverre Rabbelier wrote: >> On Tue, Feb 1, 2011 at 19:14, Jeff King <peff@peff.net> wrote: >> > i.e., make refs/remotes/* an actual mirror of selected parts of the >> > remote's refs/ hierarchy. And then figure out sane rules for merging >> > those namespaces into the ref lookup procedure. >> >> Jeff, Nguy, are either of you interested in writing up a new/modifying >> this proposal to be about namespacing everything? > > Here's my go at phrasing this in a proposal format. Feel free to revise and > resend: > +1 > > Proposal: > > Currently, git stores remote refs in the local repo by default as follows: > > Remote repo -> Local repo > --------------------------------------------------------- > HEAD refs/remotes/$remote/HEAD (implicit) > refs/heads/* refs/remotes/$remote/* > refs/tags/* refs/tags/* (implicit, autofollow) > refs/replace/* (TBD) > refs/notes/* (TBD) > > Several users report that they are confused by the difference in how heads > and tags are mapped, and by the implicit mappings that are not mentioned in > the configured refspecs. Also, as users want to share ever more different > types of refs (replace refs and notes refs have been discussed recently), > the existing ref mappings (aka. refspecs) do not suggest a natural/intuitive > mapping for the new ref types. > > Instead, we should change the default ref mappings into the following: > > Remote repo -> Local repo > -------------------------------------------------- > HEAD refs/remotes/$remote/HEAD > refs/heads/* refs/remotes/$remote/heads/* > refs/tags/* refs/remotes/$remote/tags/* > refs/replace/* refs/remotes/$remote/replace/* > refs/notes/* refs/remotes/$remote/notes/* [...] > - We might want to generalize the handling of "$remote/$head" into allowing > shorthands like "$remote/$tag", "$remote/$replace" and "$remote/$note" as > well (provided, of course, that they match unambiguously). [...] > [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local tag > (refs/tags/v1.7.4) is found, then we have an unambiguous match. If no local > tag is found, we look up the tag name in all configured remotes (using the > method described in [1]). If the tag name exists in one or more remotes, and > those remotes all agree on its ultimate object name (after applying e.g. > ^{commit} or whatever is appropriate in the context of the lookup), then we > also have an unambiguous match. However, if the tag name exists in multiple > remotes, and they do NOT all agree on its ultimate object name, then the > shorthand tag name is ambiguous and the lookup fails. The user can always > resolve this ambiguity by creating a local tag (refs/tags/v1.7.4) pointing > to the desired object. And the other way around. What would be the output of "git name-rev" , "git describe", "--decorate", and such? $remote/tags/$tag? $remote/$tag? $tag? I would say $remote/$tag for "git name-rev" and "--decorate" but $tag for "git describe" as it is usually used to create files, i.e. git-1.7.4.261.g705f.tar.gz. And I think many people, me included, do not expect to have an / in the "git describe" output, at least in the default output (in contrast with the --all flag). Another point to consider is if we want a default remote for tags, a config tags.defaultRemote (TBD), defaulting to origin, specifying the default remote for tags. There would be a hierarchy: local tags, default remote tags, remote tags. With this if one tag is on multiple remote the tag from the default remote always wins. In this way all the tag related input/output would no change much. For example all the decoration would be $tag instead of origin/tag. HTH, Santi ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-02 13:27 ` Santi Béjar @ 2011-02-02 15:51 ` Johan Herland 2011-02-02 16:19 ` Santi Béjar 0 siblings, 1 reply; 104+ messages in thread From: Johan Herland @ 2011-02-02 15:51 UTC (permalink / raw) To: Santi Béjar Cc: git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre, johan On Wednesday 02 February 2011, Santi Béjar wrote: > On Wednesday 02 February 2011, Johan Herland wrote: > > Proposal: > > > > Currently, git stores remote refs in the local repo by default as > > follows: > > > > Remote repo -> Local repo > > --------------------------------------------------------- > > HEAD refs/remotes/$remote/HEAD (implicit) > > refs/heads/* refs/remotes/$remote/* > > refs/tags/* refs/tags/* (implicit, autofollow) > > refs/replace/* (TBD) > > refs/notes/* (TBD) > > > > Instead, we should change the default ref mappings into the > > following: > > > > Remote repo -> Local repo > > -------------------------------------------------- > > HEAD refs/remotes/$remote/HEAD > > refs/heads/* refs/remotes/$remote/heads/* > > refs/tags/* refs/remotes/$remote/tags/* > > refs/replace/* refs/remotes/$remote/replace/* > > refs/notes/* refs/remotes/$remote/notes/* > > [...] > > > - We might want to generalize the handling of "$remote/$head" into > > allowing shorthands like "$remote/$tag", "$remote/$replace" and > > "$remote/$note" as well (provided, of course, that they match > > unambiguously). > > [...] > > > [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local > > tag (refs/tags/v1.7.4) is found, then we have an unambiguous match. > > If no local tag is found, we look up the tag name in all configured > > remotes (using the method described in [1]). If the tag name exists > > in one or more remotes, and those remotes all agree on its ultimate > > object name (after applying e.g. ^{commit} or whatever is > > appropriate in the context of the lookup), then we also have an > > unambiguous match. However, if the tag name exists in multiple > > remotes, and they do NOT all agree on its ultimate object name, > > then the shorthand tag name is ambiguous and the lookup fails. The > > user can always resolve this ambiguity by creating a local tag > > (refs/tags/v1.7.4) pointing to the desired object. > > And the other way around. What would be the output of "git name-rev" > , "git describe", "--decorate", and such? $remote/tags/$tag? > $remote/$tag? $tag? > > I would say $remote/$tag for "git name-rev" and "--decorate" but $tag > for "git describe" as it is usually used to create files, i.e. > git-1.7.4.261.g705f.tar.gz. And I think many people, me included, do > not expect to have an / in the "git describe" output, at least in the > default output (in contrast with the --all flag). Thanks for raising an important point. I don't buy the file name creation argument, as 'describe' is used from many different contexts, and file name creation is nowhere documented as one of its primary objectives. Still, the objective of 'describe' is to create a human-readable string that tries to say something meaningful about a commit in relation to its preceding history, while at the same time uniquely identifying the commit. The "uniquely identifying" part is taken care of by the "-g<SHA1>" part of the output, while the initial "<tagname>-<n>" part makes it human-friendly. Therefore, we only care that the <tagname> is fairly unambiguous in the mind of the reader. From this perspective, which of the alternatives makes more sense? I would disqualify "$remote/$tag" and "$remote/tags/$tag", since the $remote name is repo-specific, and 'describe' output is often passed around between multiple developers/repos. Hence, I think that "$tag" is a good choice for 'describe'. If "$tag" is ambiguous in the current repo, then an "ambiguous tag" tag warning can be printed, but I would still use "$tag". When it comes to 'name-rev' and '--decorate', those are (AFAICS) much more repo-specific, and seldom passed between users. Also, they don't have the "-g<SHA1>" part from the 'describe' output. Hence, in this case, I consider unique identification (unambiguity) much more important than not displaying $remote names. Therefore, I'd propose using the shortest unambiguous alternative. > Another point to consider is if we want a default remote for tags, a > config tags.defaultRemote (TBD), defaulting to origin, specifying the > default remote for tags. There would be a hierarchy: local tags, > default remote tags, remote tags. With this if one tag is on multiple > remote the tag from the default remote always wins. > > In this way all the tag related input/output would no change much. > For example all the decoration would be $tag instead of origin/tag. Agreed, tags.defaultRemote (or tags.preferredRemote if I'm allowed to bikeshed) may be a valuable addition. Another way to achieve this would be to explicitly copy tags from the preferred remote (e.g. origin) directly into refs/tags. I.e. in addition to the (new) default tag refspec +refs/tags/*:refs/remotes/origin/tags/* you could add an _additional_ refspec refs/tags/*:refs/tags/* that would also copy all of origin's tags directly into your local tag namespace. Thanks for the feedback! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-02 15:51 ` Johan Herland @ 2011-02-02 16:19 ` Santi Béjar 0 siblings, 0 replies; 104+ messages in thread From: Santi Béjar @ 2011-02-02 16:19 UTC (permalink / raw) To: Johan Herland Cc: git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Wed, Feb 2, 2011 at 4:51 PM, Johan Herland <johan@herland.net> wrote: > On Wednesday 02 February 2011, Santi Béjar wrote: >> On Wednesday 02 February 2011, Johan Herland wrote: >> > Proposal: >> > >> > Currently, git stores remote refs in the local repo by default as >> > follows: >> > >> > Remote repo -> Local repo >> > --------------------------------------------------------- >> > HEAD refs/remotes/$remote/HEAD (implicit) >> > refs/heads/* refs/remotes/$remote/* >> > refs/tags/* refs/tags/* (implicit, autofollow) >> > refs/replace/* (TBD) >> > refs/notes/* (TBD) >> > >> > Instead, we should change the default ref mappings into the >> > following: >> > >> > Remote repo -> Local repo >> > -------------------------------------------------- >> > HEAD refs/remotes/$remote/HEAD >> > refs/heads/* refs/remotes/$remote/heads/* >> > refs/tags/* refs/remotes/$remote/tags/* >> > refs/replace/* refs/remotes/$remote/replace/* >> > refs/notes/* refs/remotes/$remote/notes/* >> >> [...] >> >> > - We might want to generalize the handling of "$remote/$head" into >> > allowing shorthands like "$remote/$tag", "$remote/$replace" and >> > "$remote/$note" as well (provided, of course, that they match >> > unambiguously). >> >> [...] >> >> > [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local >> > tag (refs/tags/v1.7.4) is found, then we have an unambiguous match. >> > If no local tag is found, we look up the tag name in all configured >> > remotes (using the method described in [1]). If the tag name exists >> > in one or more remotes, and those remotes all agree on its ultimate >> > object name (after applying e.g. ^{commit} or whatever is >> > appropriate in the context of the lookup), then we also have an >> > unambiguous match. However, if the tag name exists in multiple >> > remotes, and they do NOT all agree on its ultimate object name, >> > then the shorthand tag name is ambiguous and the lookup fails. The >> > user can always resolve this ambiguity by creating a local tag >> > (refs/tags/v1.7.4) pointing to the desired object. >> >> And the other way around. What would be the output of "git name-rev" >> , "git describe", "--decorate", and such? $remote/tags/$tag? >> $remote/$tag? $tag? >> >> I would say $remote/$tag for "git name-rev" and "--decorate" but $tag >> for "git describe" as it is usually used to create files, i.e. >> git-1.7.4.261.g705f.tar.gz. And I think many people, me included, do >> not expect to have an / in the "git describe" output, at least in the >> default output (in contrast with the --all flag). > > Thanks for raising an important point. > > I don't buy the file name creation argument, as 'describe' is used from > many different contexts, and file name creation is nowhere documented > as one of its primary objectives. Yes, I know it is used from many different contexts, but one important one is the creation of the tar files, even git.git's Makefile assumes this. But as at the end we agree... > > Still, the objective of 'describe' is to create a human-readable string > that tries to say something meaningful about a commit in relation to > its preceding history, while at the same time uniquely identifying the > commit. The "uniquely identifying" part is taken care of by > the "-g<SHA1>" part of the output, while the initial "<tagname>-<n>" > part makes it human-friendly. Therefore, we only care that the > <tagname> is fairly unambiguous in the mind of the reader. From this > perspective, which of the alternatives makes more sense? I would > disqualify "$remote/$tag" and "$remote/tags/$tag", since the $remote > name is repo-specific, and 'describe' output is often passed around > between multiple developers/repos. Hence, I think that "$tag" is a good > choice for 'describe'. If "$tag" is ambiguous in the current repo, then > an "ambiguous tag" tag warning can be printed, but I would still > use "$tag". > > When it comes to 'name-rev' and '--decorate', those are (AFAICS) much > more repo-specific, and seldom passed between users. Also, they don't > have the "-g<SHA1>" part from the 'describe' output. Hence, in this > case, I consider unique identification (unambiguity) much more > important than not displaying $remote names. Therefore, I'd propose > using the shortest unambiguous alternative. I agree. Something like this I had in mind :) > >> Another point to consider is if we want a default remote for tags, a >> config tags.defaultRemote (TBD), defaulting to origin, specifying the >> default remote for tags. There would be a hierarchy: local tags, >> default remote tags, remote tags. With this if one tag is on multiple >> remote the tag from the default remote always wins. >> >> In this way all the tag related input/output would no change much. >> For example all the decoration would be $tag instead of origin/tag. > > Agreed, tags.defaultRemote (or tags.preferredRemote if I'm allowed to > bikeshed) may be a valuable addition. Another way to achieve this would > be to explicitly copy tags from the preferred remote (e.g. origin) > directly into refs/tags. I.e. in addition to the (new) default tag > refspec > > +refs/tags/*:refs/remotes/origin/tags/* > > you could add an _additional_ refspec > > refs/tags/*:refs/tags/* > > that would also copy all of origin's tags directly into your local tag > namespace. Yes, you always can add this refspec but I don't want to pollute my "strict" local tags. And moreover with the config tags.preferredRemote you can change from one preferred remote to another just changing a config. > Thanks for the feedback! :) Thanks for the proposal! HTH, Santi ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-02 2:21 ` [1.8.0] Provide proper remote ref namespaces Johan Herland 2011-02-02 13:27 ` Santi Béjar @ 2011-02-03 5:33 ` Nguyen Thai Ngoc Duy 2011-02-03 8:46 ` Johan Herland 2011-02-03 11:35 ` Nguyen Thai Ngoc Duy 2011-02-04 22:39 ` Junio C Hamano 3 siblings, 1 reply; 104+ messages in thread From: Nguyen Thai Ngoc Duy @ 2011-02-03 5:33 UTC (permalink / raw) To: Johan Herland; +Cc: git, Sverre Rabbelier, Jeff King, Nicolas Pitre On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net> wrote: > Migration plan: > ... > In v1.8.0, we should default to the new default refspecs when creating new > remotes. However, existing remotes (created pre-v1.8.0) must continue to > work as before, so we cannot simply remove the implicit refspecs (or tag > auto-following). Instead we need to make sure that the implicit refspecs is > NOT applied to the new-style remotes. Identifying new-style vs. old-style > remotes can be done by looking at the refspec itself (old-style: > "refs/remotes/$remote/*", new-style: "refs/remotes/$remote/heads/*"), or > (worst case) by introducing a config variable specifying the desired > behavior (defaulting to old-style). How about convert old style remotes to new style? Should it be done automatically when new git detects old style remotes, or done by command, or manually? -- Duy ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-03 5:33 ` Nguyen Thai Ngoc Duy @ 2011-02-03 8:46 ` Johan Herland 0 siblings, 0 replies; 104+ messages in thread From: Johan Herland @ 2011-02-03 8:46 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy; +Cc: git, Sverre Rabbelier, Jeff King, Nicolas Pitre On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote: > On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net> wrote: > > Migration plan: > > ... > > In v1.8.0, we should default to the new default refspecs when creating > > new remotes. However, existing remotes (created pre-v1.8.0) must > > continue to work as before, so we cannot simply remove the implicit > > refspecs (or tag auto-following). Instead we need to make sure that > > the implicit refspecs is NOT applied to the new-style remotes. > > Identifying new-style vs. old-style remotes can be done by looking at > > the refspec itself (old-style: "refs/remotes/$remote/*", new-style: > > "refs/remotes/$remote/heads/*"), or (worst case) by introducing a > > config variable specifying the desired behavior (defaulting to > > old-style). > > How about convert old style remotes to new style? Should it be done > automatically when new git detects old style remotes, or done by > command, or manually? I don't think we want to mess with existing remote refs without the user's consent, especially since the user might have all kinds of repo-specific practices tied to the old layout of remote refs. Providing a command to do it (git remote renew?) is a much better way to go about it, IMHO. Still, it is vitally important that new git keeps working with old-style remotes. Another issue is whether we should automatically make the old-style implicit refspecs into _explicit_ (but still old-style) refspecs. I.e. when encountering an old-style remote, new git could automatically add the following refspecs to the remote: +HEAD:refs/remotes/origin/HEAD ~refs/tags/*:refs/tags/* ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-02 2:21 ` [1.8.0] Provide proper remote ref namespaces Johan Herland 2011-02-02 13:27 ` Santi Béjar 2011-02-03 5:33 ` Nguyen Thai Ngoc Duy @ 2011-02-03 11:35 ` Nguyen Thai Ngoc Duy 2011-02-03 13:10 ` Johan Herland 2011-02-04 22:39 ` Junio C Hamano 3 siblings, 1 reply; 104+ messages in thread From: Nguyen Thai Ngoc Duy @ 2011-02-03 11:35 UTC (permalink / raw) To: Johan Herland; +Cc: git, Sverre Rabbelier, Jeff King, Nicolas Pitre On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net> wrote: > Migration plan: > ... > In v1.8.0, we should default to the new default refspecs when creating new > remotes. However, existing remotes (created pre-v1.8.0) must continue to > work as before, so we cannot simply remove the implicit refspecs (or tag > auto-following). Instead we need to make sure that the implicit refspecs is > NOT applied to the new-style remotes. Identifying new-style vs. old-style > remotes can be done by looking at the refspec itself (old-style: > "refs/remotes/$remote/*", new-style: "refs/remotes/$remote/heads/*"), or > (worst case) by introducing a config variable specifying the desired > behavior (defaulting to old-style). I'd prefer config var (remote.*.implicitRules, maybe). We don't reserve heads, tags... in remote namespace for ourselves. Some users might have already have branches heads/ant, heads/bee... making new style detection unreliable. So I propose add remote.*.implicitRules = false since 1.8.0 for new remotes as a way to detect new/old style. The default value would be true. But I don't want to keep adding remote.*.implicitRules on new remotes forever. I suppose one year after 1.8.0, the new behavior is widespread enough. We can then annoy users to add remote.*.implicitRules for all old remotes. There should be no more default value after 1-2 years. We then flip the default value and won't automatically add remote.*.implicitRules = false on new remotes. -- Duy ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-03 11:35 ` Nguyen Thai Ngoc Duy @ 2011-02-03 13:10 ` Johan Herland 2011-02-03 14:10 ` Santi Béjar 0 siblings, 1 reply; 104+ messages in thread From: Johan Herland @ 2011-02-03 13:10 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy; +Cc: git, Sverre Rabbelier, Jeff King, Nicolas Pitre On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote: > On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net> wrote: > > Migration plan: > > ... > > In v1.8.0, we should default to the new default refspecs when > > creating new remotes. However, existing remotes (created > > pre-v1.8.0) must continue to work as before, so we cannot simply > > remove the implicit refspecs (or tag auto-following). Instead we > > need to make sure that the implicit refspecs is NOT applied to the > > new-style remotes. Identifying new-style vs. old-style remotes can > > be done by looking at the refspec itself (old-style: > > "refs/remotes/$remote/*", new-style: > > "refs/remotes/$remote/heads/*"), or (worst case) by introducing a > > config variable specifying the desired behavior (defaulting to > > old-style). > > I'd prefer config var (remote.*.implicitRules, maybe). We don't > reserve heads, tags... in remote namespace for ourselves. Some users > might have already have branches heads/ant, heads/bee... making new > style detection unreliable. > > So I propose add remote.*.implicitRules = false since 1.8.0 for new > remotes as a way to detect new/old style. The default value would be > true. > > But I don't want to keep adding remote.*.implicitRules on new remotes > forever. I suppose one year after 1.8.0, the new behavior is > widespread enough. We can then annoy users to add > remote.*.implicitRules for all old remotes. There should be no more > default value after 1-2 years. We then flip the default value and > won't automatically add remote.*.implicitRules = false on new > remotes. I don't have a problem with this, other than bikeshedding over the variable name: I find remote.*.implicitFetchRefspecs more descriptive. ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-03 13:10 ` Johan Herland @ 2011-02-03 14:10 ` Santi Béjar 2011-02-03 15:48 ` Nguyen Thai Ngoc Duy 0 siblings, 1 reply; 104+ messages in thread From: Santi Béjar @ 2011-02-03 14:10 UTC (permalink / raw) To: Johan Herland Cc: Nguyen Thai Ngoc Duy, git, Sverre Rabbelier, Jeff King, Nicolas Pitre > On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote: >> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net> > wrote: >> > Migration plan: >> > ... >> > In v1.8.0, we should default to the new default refspecs when >> > creating new remotes. However, existing remotes (created >> > pre-v1.8.0) must continue to work as before, so we cannot simply >> > remove the implicit refspecs (or tag auto-following). Instead we >> > need to make sure that the implicit refspecs is NOT applied to the >> > new-style remotes. Identifying new-style vs. old-style remotes can >> > be done by looking at the refspec itself (old-style: >> > "refs/remotes/$remote/*", new-style: >> > "refs/remotes/$remote/heads/*"), or (worst case) by introducing a >> > config variable specifying the desired behavior (defaulting to >> > old-style). >> >> I'd prefer config var (remote.*.implicitRules, maybe). We don't >> reserve heads, tags... in remote namespace for ourselves. Some users >> might have already have branches heads/ant, heads/bee... making new >> style detection unreliable. I don't quite follow the argument. For me the question is how likely an old-time user has modified the refspec to read "refs/remotes/$remote/heads/* (new-style). I think this is very, very unlikely and thus the "heuristic" to detect old/new style works most of the time and there is no need for a new config/compatibility key. HTH, Santi ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-03 14:10 ` Santi Béjar @ 2011-02-03 15:48 ` Nguyen Thai Ngoc Duy 0 siblings, 0 replies; 104+ messages in thread From: Nguyen Thai Ngoc Duy @ 2011-02-03 15:48 UTC (permalink / raw) To: Santi Béjar Cc: Johan Herland, git, Sverre Rabbelier, Jeff King, Nicolas Pitre On Thu, Feb 3, 2011 at 9:10 PM, Santi Béjar <santi@agolina.net> wrote: >> On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote: >>> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net> >> wrote: >>> > Migration plan: >>> > ... >>> > In v1.8.0, we should default to the new default refspecs when >>> > creating new remotes. However, existing remotes (created >>> > pre-v1.8.0) must continue to work as before, so we cannot simply >>> > remove the implicit refspecs (or tag auto-following). Instead we >>> > need to make sure that the implicit refspecs is NOT applied to the >>> > new-style remotes. Identifying new-style vs. old-style remotes can >>> > be done by looking at the refspec itself (old-style: >>> > "refs/remotes/$remote/*", new-style: >>> > "refs/remotes/$remote/heads/*"), or (worst case) by introducing a >>> > config variable specifying the desired behavior (defaulting to >>> > old-style). >>> >>> I'd prefer config var (remote.*.implicitRules, maybe). We don't >>> reserve heads, tags... in remote namespace for ourselves. Some users >>> might have already have branches heads/ant, heads/bee... making new >>> style detection unreliable. > > I don't quite follow the argument. For me the question is how likely > an old-time user has modified the refspec to read > "refs/remotes/$remote/heads/* (new-style). I think this is very, very > unlikely and thus the "heuristic" to detect old/new style works most > of the time and there is no need for a new config/compatibility key. Personally I don't have any repos that weird, so it's no problem to me. Maybe I'm overengineering. -- Duy ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-02 2:21 ` [1.8.0] Provide proper remote ref namespaces Johan Herland ` (2 preceding siblings ...) 2011-02-03 11:35 ` Nguyen Thai Ngoc Duy @ 2011-02-04 22:39 ` Junio C Hamano 2011-02-05 1:18 ` Johan Herland 2011-02-05 18:39 ` Nicolas Pitre 3 siblings, 2 replies; 104+ messages in thread From: Junio C Hamano @ 2011-02-04 22:39 UTC (permalink / raw) To: Johan Herland Cc: git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: > - Remote tags are now stored separate from local tags. When looking up a > shorthand tag name (e.g. v1.7.4), we should consult local tags > (refs/tags/v1.7.4) before remote tags (refs/remotes/*/tags/v1.7.4 [1]). See > [2] for more details. > - Remote heads have moved into refs/remotes/$remote/heads/*, hence > invalidating shorthand remote head names, like "origin/master". We should > change the lookup code, so that a shorthand ref of the form "$remote/$head" > where "$remote" happens to match a configured remote is eventually expanded > into lookup for "refs/remotes/$remote/heads/$head" [3]. Keeping 'origin/next' usable is a _must_, _if_ we were to go this route. > - We might want to generalize the handling of "$remote/$head" into allowing > shorthands like "$remote/$tag", "$remote/$replace" and "$remote/$note" as > well (provided, of course, that they match unambiguously). > > - All fetch refspecs should be given explicitly. What do you mean by this? > Sub-proposal: While we are changing the default refspecs, we should also > consider whether we want to keep the auto-following behavior that Git > currently does for tags (don't fetch tags that refer to objects not > otherwise fetched by another refspec). If we simply make an explicit > "+refs/tags/*:refs/remotes/$remote/tags/*" refspec, we will lose the auto- > following behavior. If we do want to keep the auto-following behavior, we > could for example add a "~" prefix to the refspec to trigger auto-following > behavior (i.e. this refspec only applies to refs that happen to point at > objects fetched by way of a different refspec). See > http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160795 > for more details. You seem to envision "auto-follow" to slurp remote tags in remotes/origin/$tag namespace. What should "git fetch --tags $from_there" do? For some reason, many people seem to be enthused about splitting the tag namespace, but I am not sure if that is a good thing in general. Branches are moving pointers for people to flip around in their local repositories, and it makes sense to say "My master is a bit ahead of the public one", but what would we gain by making it _easier_ to add and exchange many tags with the same name (e.g. refs/remotes/*/tags/v1.7.4 vs refs/tags/v1.7.4), other than the extra confusion? While you are talking about drastic reorganization (and rewriting the ref code to support it), another possible Sub-proposal we may want to consider is to allow "next" and "next/foo" at the same time. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-04 22:39 ` Junio C Hamano @ 2011-02-05 1:18 ` Johan Herland 2011-02-05 18:00 ` Kevin P. Fleming 2011-02-05 21:40 ` Dmitry Potapov 2011-02-05 18:39 ` Nicolas Pitre 1 sibling, 2 replies; 104+ messages in thread From: Johan Herland @ 2011-02-05 1:18 UTC (permalink / raw) To: Junio C Hamano Cc: git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Friday 04 February 2011, Junio C Hamano wrote: > Johan Herland <johan@herland.net> writes: > > - Remote heads have moved into refs/remotes/$remote/heads/*, hence > > invalidating shorthand remote head names, like "origin/master". We > > should change the lookup code, so that a shorthand ref of the form > > "$remote/$head" where "$remote" happens to match a configured remote > > is eventually expanded into lookup for > > "refs/remotes/$remote/heads/$head" [3]. > > Keeping 'origin/next' usable is a _must_, _if_ we were to go this route. Of course. > > - All fetch refspecs should be given explicitly. > > What do you mean by this? Today, when you fetch from a remote, the config typically says [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = ... But this fetch refspec does not tell the full story. In addition to mapping origin's refs/heads/* into refs/remotes/origin/*, it also fetches origin's HEAD into refs/remotes/origin/HEAD, and anything in origin's refs/tags/* that happen to point to a fetched object is fetched into refs/tags/* (aka. auto-following tags). These other fetches are not explicitly specified in the config, but "magically" happen anyway. Instead of having such implicit refspecs, I'd rather have all fetch refspecs listed explicitly in the config, like this (for replicating current layout): [remote "origin"] fetch = +HEAD:refs/remotes/origin/HEAD fetch = +refs/heads/*:refs/remotes/origin/* fetch = ~refs/tags/*:refs/tags/* url = ... or this (in the proposed new layout): [remote "origin"] fetch = +HEAD:refs/remotes/origin/HEAD fetch = +refs/heads/*:refs/remotes/origin/heads* fetch = +refs/tags/*:refs/remotes/origin/tags/* url = ... > > Sub-proposal: While we are changing the default refspecs, we should > > also consider whether we want to keep the auto-following behavior that > > Git currently does for tags (don't fetch tags that refer to objects > > not otherwise fetched by another refspec). If we simply make an > > explicit "+refs/tags/*:refs/remotes/$remote/tags/*" refspec, we will > > lose the auto- following behavior. If we do want to keep the > > auto-following behavior, we could for example add a "~" prefix to the > > refspec to trigger auto-following behavior (i.e. this refspec only > > applies to refs that happen to point at objects fetched by way of a > > different refspec). See > > http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160 > > 795 for more details. > > You seem to envision "auto-follow" to slurp remote tags in > remotes/origin/$tag namespace. What should "git fetch --tags $from_there" > do? I would propose that "git fetch --tags $from_there" follows these steps: 1. Enumerate the (implicit or explicit) fetch refspecs for the given remote. 2. Map "refs/tags/*" through the refspecs to find where the remote tags should be stored in the local repo. 3. If the matching refspec starts with "~" (auto-following), disregard the "~" (since --tags disables auto-following). 4. Slurp remote tags into the location found in step #2. Since we map through the refspec, the remote tags end up where the user expect to find them: in refs/tags/* for old-style remotes, or in refs/remotes/$from_there/tags/* for new-style remotes. > For some reason, many people seem to be enthused about splitting the tag > namespace, but I am not sure if that is a good thing in general. > Branches are moving pointers for people to flip around in their local > repositories, and it makes sense to say "My master is a bit ahead of the > public one", but what would we gain by making it _easier_ to add and > exchange many tags with the same name (e.g. refs/remotes/*/tags/v1.7.4 > vs refs/tags/v1.7.4), other than the extra confusion? First, I should state that making tags into moving pointers is not something I support, nor is it part of this proposal. Tags should still very much refuse to be moved (except when forced). Having said that, there are real situations where users encounter collisions in the shared tag namespace. A rare (but plausible) scenario arise when two developers create (and publish) conflicting tags in their repos. A more common scenario that I have encountered at $dayjob, is where two parallel (semi-related) projects are developed in separate repos (with different versioning because of separate release schedules), and I need to interface with both repos from a single local repo. Each of the remote repos have their own "v1.0" tag, but my repo can only hold one such tag. Which of those tags end up "winning" in my local repo depends on my fetch order. Git already has code to discover ambiguous ref names, and we have powerful tools for inspecting the history and diffs between local and remote branches. But because we conflate tags into a single namespace, we cannot easily use these tools when circumstances conspire to produce conflicting tags. Putting remote tags into separate namespaces allows us to use the same tools that we use on remote branches, to discover and inspect conflicting tags when (if only rarely) they do happen. Another advantage of splitting tags into separate namespaces is that the "source" or "domain" of a tag becomes slightly less foggy: Consider a tag "foo" that may exist as refs/remotes/origin/tags/foo (remote/public) and/or as refs/tags/foo (local/private). If it exists only locally, it may be a hint that this is a "private" tag (not intended for public consumption). If it exists only remotely, it's obviously a public tag. If it exists both locally and remotely (without conflict), it may indicate that this is a public tag that was originally created in this repo. > While you are talking about drastic reorganization (and rewriting the ref > code to support it), another possible Sub-proposal we may want to > consider is to allow "next" and "next/foo" at the same time. Interesting. I haven't followed this discussion lately (if there has been any), but I guess we need to find a new way to organize loose refs that doesn't cause file vs. directory problems. Obviously, the packed-refs format should have no inherent problem with these refs, but I guess we can't drop loose ref support completely. One sort-of-workaround could be to detect when "next" vs. "next/foo" happens, and simply force one of them to be a packed ref. Have fun! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-05 1:18 ` Johan Herland @ 2011-02-05 18:00 ` Kevin P. Fleming 2011-02-05 21:40 ` Dmitry Potapov 1 sibling, 0 replies; 104+ messages in thread From: Kevin P. Fleming @ 2011-02-05 18:00 UTC (permalink / raw) To: Johan Herland Cc: Junio C Hamano, git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On 02/05/2011 02:18 AM, Johan Herland wrote: > Today, when you fetch from a remote, the config typically says > > [remote "origin"] > fetch = +refs/heads/*:refs/remotes/origin/* > url = ... > > But this fetch refspec does not tell the full story. In addition to mapping > origin's refs/heads/* into refs/remotes/origin/*, it also fetches origin's > HEAD into refs/remotes/origin/HEAD, and anything in origin's refs/tags/* > that happen to point to a fetched object is fetched into refs/tags/* (aka. > auto-following tags). These other fetches are not explicitly specified in > the config, but "magically" happen anyway. Instead of having such implicit > refspecs, I'd rather have all fetch refspecs listed explicitly in the > config, like this (for replicating current layout): > > [remote "origin"] > fetch = +HEAD:refs/remotes/origin/HEAD > fetch = +refs/heads/*:refs/remotes/origin/* > fetch = ~refs/tags/*:refs/tags/* > url = ... > > or this (in the proposed new layout): > > [remote "origin"] > fetch = +HEAD:refs/remotes/origin/HEAD > fetch = +refs/heads/*:refs/remotes/origin/heads* > fetch = +refs/tags/*:refs/remotes/origin/tags/* > url = ... I would appreciate this as well; the less implicit behavior in areas like this, the better :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-05 1:18 ` Johan Herland 2011-02-05 18:00 ` Kevin P. Fleming @ 2011-02-05 21:40 ` Dmitry Potapov 2011-02-06 0:04 ` Johan Herland 1 sibling, 1 reply; 104+ messages in thread From: Dmitry Potapov @ 2011-02-05 21:40 UTC (permalink / raw) To: Johan Herland Cc: Junio C Hamano, git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Sat, Feb 05, 2011 at 02:18:44AM +0100, Johan Herland wrote: > On Friday 04 February 2011, Junio C Hamano wrote: > > > For some reason, many people seem to be enthused about splitting the tag > > namespace, but I am not sure if that is a good thing in general. > > Branches are moving pointers for people to flip around in their local > > repositories, and it makes sense to say "My master is a bit ahead of the > > public one", but what would we gain by making it _easier_ to add and > > exchange many tags with the same name (e.g. refs/remotes/*/tags/v1.7.4 > > vs refs/tags/v1.7.4), other than the extra confusion? > > First, I should state that making tags into moving pointers is not something > I support, nor is it part of this proposal. Tags should still very much > refuse to be moved (except when forced). > > Having said that, there are real situations where users encounter collisions > in the shared tag namespace. A rare (but plausible) scenario arise when two > developers create (and publish) conflicting tags in their repos. A more > common scenario that I have encountered at $dayjob, is where two parallel > (semi-related) projects are developed in separate repos (with different > versioning because of separate release schedules), and I need to interface > with both repos from a single local repo. Each of the remote repos have > their own "v1.0" tag, but my repo can only hold one such tag. Which of those > tags end up "winning" in my local repo depends on my fetch order. Well, I agree that this situation requires a better diagnostic, but I don't think that having separate namespaces is the right solution in general. For your case, where you work on semi-related projects, it is could be the right thing to do, but if you work on the same project and have more than one source to fetch, then having multiple namespaces can lead only to confusion, because tag names must be unique globally to make sense to everyone. Actually, even if you have two semi-related projects in the same repository, but you have more than one URL per project, you want to group tags based on their relation to the project and not based on the URL. Dmitry ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-05 21:40 ` Dmitry Potapov @ 2011-02-06 0:04 ` Johan Herland 2011-02-06 12:03 ` Dmitry Potapov 2011-02-06 20:28 ` Matthieu Moy 0 siblings, 2 replies; 104+ messages in thread From: Johan Herland @ 2011-02-06 0:04 UTC (permalink / raw) To: Dmitry Potapov Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Saturday 05 February 2011, Dmitry Potapov wrote: > On Sat, Feb 05, 2011 at 02:18:44AM +0100, Johan Herland wrote: > > Having said that, there are real situations where users encounter > > collisions in the shared tag namespace. A rare (but plausible) > > scenario arise when two developers create (and publish) conflicting > > tags in their repos. A more common scenario that I have encountered at > > $dayjob, is where two parallel (semi-related) projects are developed > > in separate repos (with different versioning because of separate > > release schedules), and I need to interface with both repos from a > > single local repo. Each of the remote repos have their own "v1.0" tag, > > but my repo can only hold one such tag. Which of those tags end up > > "winning" in my local repo depends on my fetch order. > > Well, I agree that this situation requires a better diagnostic, but I > don't think that having separate namespaces is the right solution in > general. For your case, where you work on semi-related projects, it is > could be the right thing to do, but if you work on the same project and > have more than one source to fetch, then having multiple namespaces can > lead only to confusion, because tag names must be unique globally to > make sense to everyone. Actually, even if you have two semi-related > projects in the same repository, but you have more than one URL per > project, you want to group tags based on their relation to the project > and not based on the URL. I'm not sure what problem you're describing here. Let's assume that my repo has multiple remotes (URLs), but they're all fundamentally part of the same project. If there is a tag "foo" in one remote/namespace, and a tag "foo" in a different remote/namespace, they (in the common case) point to the same object, since they - as you say - "must be unique globally to make sense to everyone". As long as they point to the same object, there's no ambiguity, and when you simply refer to tag "foo" (without specifying namespace) it all works, like today. (Read footnote [2] of my proposal for more details on handling ambiguity in tag names.) However, when the remote tags point to different objects (i.e. the uncommon case), there is an ambiguity, and we should deal with that ambiguity properly, instead of silently adopting one of them arbitrarily. I don't see how the separate namespaces cause problems here. Also, I don't know what you're proposing instead, or indeed what other organization of tags would lead to less confusion. Have fun! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 0:04 ` Johan Herland @ 2011-02-06 12:03 ` Dmitry Potapov 2011-02-06 14:09 ` Nicolas Pitre 2011-02-06 16:11 ` Johan Herland 2011-02-06 20:28 ` Matthieu Moy 1 sibling, 2 replies; 104+ messages in thread From: Dmitry Potapov @ 2011-02-06 12:03 UTC (permalink / raw) To: Johan Herland Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Sun, Feb 06, 2011 at 01:04:36AM +0100, Johan Herland wrote: >_ > As long as they point to the same object, there's no ambiguity, and when you_ > simply refer to tag "foo" (without specifying namespace) it all works, like_ > today. (Read footnote [2] of my proposal for more details on handling_ > ambiguity in tag names.) I see no reason to create different namespaces, because semantically there is only one namespace. > However, when the remote tags point to different objects (i.e. the uncommon_ > case), there is an ambiguity, and we should deal with that ambiguity_ > properly, instead of silently adopting one of them arbitrarily. To me, the proper handling ambiguity means that when I do "git fetch" I immediately see warning about tag clashes. So, I agree with you that current behavior is not good, but I disagree with you about having many namespaces, because it postpones detection of the conflict until I try to use. And well, git may detect ambiguity when I say "git show v1.0", but if I look at my branch in gitk and see "v1.0" and may say to someone that I use "v1.0" but that person looks at his tree and sees "v1.0" as something different. So, if there is two different tags with the same name, it is better to report the problem as soon as possible, i.e. during "git fetch", and then there is no reason to have separate namespaces for tags. Dmitry ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 12:03 ` Dmitry Potapov @ 2011-02-06 14:09 ` Nicolas Pitre 2011-02-06 15:17 ` Dmitry Potapov 2011-02-06 16:11 ` Johan Herland 1 sibling, 1 reply; 104+ messages in thread From: Nicolas Pitre @ 2011-02-06 14:09 UTC (permalink / raw) To: Dmitry Potapov Cc: Johan Herland, git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy On Sun, 6 Feb 2011, Dmitry Potapov wrote: > To me, the proper handling ambiguity means that when I do "git fetch" I > immediately see warning about tag clashes. Fair enough. > So, I agree with you that > current behavior is not good, but I disagree with you about having many > namespaces, because it postpones detection of the conflict until I try > to use. No. The later does not prevent the former. > And well, git may detect ambiguity when I say "git show v1.0", > but if I look at my branch in gitk and see "v1.0" and may say to someone > that I use "v1.0" but that person looks at his tree and sees "v1.0" as > something different. If gitk is smart enough to see that two tags have the same name then it should scope them so they are not ambiguous anymore, unless of course they are referring to the same thing in which case they are not ambiguous from the start. > So, if there is two different tags with the same name, it is better to > report the problem as soon as possible, i.e. during "git fetch", and > then there is no reason to have separate namespaces for tags. Of course there is a reason. What if your fetch brings in hundreds of tags (this is common for some projects) and then you want to remove that fetched branch from your repository? How do you determine which tag came from that remote repository and which tags are to be kept? Without a separate namespace this is practically impossible. Nicolas ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 14:09 ` Nicolas Pitre @ 2011-02-06 15:17 ` Dmitry Potapov 0 siblings, 0 replies; 104+ messages in thread From: Dmitry Potapov @ 2011-02-06 15:17 UTC (permalink / raw) To: Nicolas Pitre Cc: Johan Herland, git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy On Sun, Feb 06, 2011 at 09:09:26AM -0500, Nicolas Pitre wrote: > On Sun, 6 Feb 2011, Dmitry Potapov wrote: >_ > > To me, the proper handling ambiguity means that when I do "git fetch" I > > immediately see warning about tag clashes. >_ > Fair enough. >_ > > So, I agree with you that > > current behavior is not good, but I disagree with you about having many > > namespaces, because it postpones detection of the conflict until I try > > to use. >_ > No. The later does not prevent the former. But what if I really have two semi-related projects that I want to fetch into the same repository as Johan suggested? In this case, I want to have separate namespaces and no warning when I fetch. >_ > Of course there is a reason. What if your fetch brings in hundreds of_ > tags (this is common for some projects) and then you want to remove that_ > fetched branch from your repository? How do you determine which tag_ > came from that remote repository and which tags are to be kept? Without_ > a separate namespace this is practically impossible. Well, I see your use case now. Maybe the right solution is add an option that will tell whether to fetch tags into separate namespace or not, and later based on experiences, we can decide whether we want to change the default to have separate namespaces for tags. Dmitry ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 12:03 ` Dmitry Potapov 2011-02-06 14:09 ` Nicolas Pitre @ 2011-02-06 16:11 ` Johan Herland 2011-02-06 17:28 ` Dmitry Potapov 1 sibling, 1 reply; 104+ messages in thread From: Johan Herland @ 2011-02-06 16:11 UTC (permalink / raw) To: Dmitry Potapov Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Sunday 06 February 2011, Dmitry Potapov wrote: > On Sun, Feb 06, 2011 at 01:04:36AM +0100, Johan Herland wrote: > >_ > > > > As long as they point to the same object, there's no ambiguity, and > > when you_ simply refer to tag "foo" (without specifying namespace) it > > all works, like_ today. (Read footnote [2] of my proposal for more > > details on handling_ ambiguity in tag names.) > > I see no reason to create different namespaces, because semantically > there is only one namespace. In practice, there is almost always one namespace (i.e. your repo belongs to only one project with project-wide unique tags). However, in any distributed system, the only-one-namespace is fundamentally a myth. Sure, it's a convenient myth, and one that we - with good reason - strive towards fulfilling, but there are situations (described earlier in this thread) where the myth is busted. In those situations, I think the _least_ confusing thing we can do for our users is to handle all remote refs consistently, and allow them to discover/investigate the remote tags as they would other remote refs. > > However, when the remote tags point to different objects (i.e. the > > uncommon_ case), there is an ambiguity, and we should deal with that > > ambiguity_ properly, instead of silently adopting one of them > > arbitrarily. > > To me, the proper handling ambiguity means that when I do "git fetch" I > immediately see warning about tag clashes. So, I agree with you that > current behavior is not good, but I disagree with you about having many > namespaces, because it postpones detection of the conflict until I try > to use. And well, git may detect ambiguity when I say "git show v1.0", > but if I look at my branch in gitk and see "v1.0" and may say to someone > that I use "v1.0" but that person looks at his tree and sees "v1.0" as > something different. In that case it would be wrong of gitk to display "v1.0". Instead it should display a longer, unambiguous name, e.g. "origin/v1.0". > So, if there is two different tags with the same name, it is better to > report the problem as soon as possible, i.e. during "git fetch", and > then there is no reason to have separate namespaces for tags. Yes, that is an alternative solution for tags. I guess it comes down to a question of how much special treatment we want to give tags. I'd rather have consistency between how tags and other remote refs are handled. ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 16:11 ` Johan Herland @ 2011-02-06 17:28 ` Dmitry Potapov 2011-02-06 22:12 ` Johan Herland 0 siblings, 1 reply; 104+ messages in thread From: Dmitry Potapov @ 2011-02-06 17:28 UTC (permalink / raw) To: Johan Herland Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Sun, Feb 06, 2011 at 05:11:45PM +0100, Johan Herland wrote: > On Sunday 06 February 2011, Dmitry Potapov wrote: > > On Sun, Feb 06, 2011 at 01:04:36AM +0100, Johan Herland wrote: > > >_ > > > > > > As long as they point to the same object, there's no ambiguity, and > > > when you_ simply refer to tag "foo" (without specifying namespace) it > > > all works, like_ today. (Read footnote [2] of my proposal for more > > > details on handling_ ambiguity in tag names.) > >_ > > I see no reason to create different namespaces, because semantically > > there is only one namespace. >_ > In practice, there is almost always one namespace (i.e. your repo belongs to_ > only one project with project-wide unique tags). However, in any distributed_ > system, the only-one-namespace is fundamentally a myth. By your logic git 1.7.4 is a myth, because I have not specified from what repository I pull it. But, IMHO, it is a myth that having different namespaces solves the problem, because in _most_ cases, you really want to have a single namespace _semantically_, so you can communicate with other people using this tag name. In your case of semi-related projects, it should be two namespaces, because there are _two_ different projects (even if they share a lot of common history). How do I know that they are different? Because they have different release schedulers, and v1.0 means different for each of them. > > To me, the proper handling ambiguity means that when I do "git fetch" I > > immediately see warning about tag clashes. So, I agree with you that > > current behavior is not good, but I disagree with you about having many > > namespaces, because it postpones detection of the conflict until I try > > to use. And well, git may detect ambiguity when I say "git show v1.0", > > but if I look at my branch in gitk and see "v1.0" and may say to someone > > that I use "v1.0" but that person looks at his tree and sees "v1.0" as > > something different. >_ > In that case it would be wrong of gitk to display "v1.0". Instead it should_ > display a longer, unambiguous name, e.g. "origin/v1.0". But it is still ambiguous because my "origin" may be different from yours origin. It is only unambiguous when it look at it _locally_ but that makes it completely useless for communication with other people. One project should have only one version with the same tag regardless where it came from. I agree in your use case of semi-related projects you need separate namespaces. But I don't think it is how most people use git. It may be nice to have an option that will make tag namespace separate, but I do not think it should be default. Not until, it is widely tested. Dmitry ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 17:28 ` Dmitry Potapov @ 2011-02-06 22:12 ` Johan Herland 2011-02-07 0:07 ` Dmitry Potapov 0 siblings, 1 reply; 104+ messages in thread From: Johan Herland @ 2011-02-06 22:12 UTC (permalink / raw) To: Dmitry Potapov Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Sunday 06 February 2011, Dmitry Potapov wrote: > On Sun, Feb 06, 2011 at 05:11:45PM +0100, Johan Herland wrote: > > In practice, there is almost always one namespace (i.e. your repo > > belongs to_ only one project with project-wide unique tags). However, > > in any distributed_ system, the only-one-namespace is fundamentally a > > myth. > > By your logic git 1.7.4 is a myth, because I have not specified from > what repository I pull it. Yes, technically git 1.7.4 is a myth. However, by convention, we all agree what "v1.7.4" points to, and nobody seriously believe they can get away with pointing "v1.7.4" somewhere else. The core of this discussion is where we want to place Git in the space between "technically correct" and "socially conventional", where the former means owning up to the fact that each repo really is its own namespace, and there's no way around that in a proper DVCS, and the latter means building social convention into our tools, thereby making it harder to deal with the few unconventional cases (like my two semi-related repos case). AFAICS, my proposal does not harm the common case (unambiguous tags are still interpreted unambiguously, even if they may exist in multiple namespaces), while it _does_ help the uncommon case (by allowing ambiguous tags to co-exist in the same repo). Granted, if we leave all tags in a single namespace, I can still work around this by manually futzing with the configured refspecs to create ad hoc namespaces. But I _really_ hate it when I'm forced to hack around the tool, because the tool thinks it "knows better". > But, IMHO, it is a myth that having different > namespaces solves the problem, because in _most_ cases, you really want > to have a single namespace _semantically_, so you can communicate with > other people using this tag name. My proposal tries very hard to present a single namespace _semantically_ to the user in the common case (when tags are unambiguous). I'd even go as far as proposing that "git tag -l" should by default list only a single shortened tag name in the cases where there are multiple unambiguous alternatives. Alternatively, I'd suggest a compromise (already mentioned elsewhere in this thread) where we add a config variable tags.preferredRemote (defaults to "origin") which allows you to directly select which namespace you consider official. You could even implement this as physically copying refs/remotes/${tag.preferredRemote}/tags/* into refs/tags/*. > > In that case it would be wrong of gitk to display "v1.0". Instead it > > should_ display a longer, unambiguous name, e.g. "origin/v1.0". > > But it is still ambiguous because my "origin" may be different from > yours origin. It is only unambiguous when it look at it _locally_ but > that makes it completely useless for communication with other people. > One project should have only one version with the same tag regardless > where it came from. Again, you are setting "technical correctness" up against "social convention". Technically, _any_ ref name whatsoever is repo-specific and "completely useless for communication with other people". The only thing we can communicate unambiguously is SHA-1 object names. However, social conventions compel us to name our refs unambiguously and to use common sense when communicating, so that - in practice - everybody in the project knows exactly what is meant by "v1.0". It seems our opinions differ on whether Git should try to _force_ this social convention on you, or rather stick to technical correctness (with a bias towards conventional behavior as long as there no ambiguities). > I agree in your use case of semi-related projects you need separate > namespaces. But I don't think it is how most people use git. It may > be nice to have an option that will make tag namespace separate, but > I do not think it should be default. Not until, it is widely tested. Well, this _is_ the thread for discussing things "we would have done differently if we were writing Git from scratch". ;) Still, you have yet to convince me exactly _what_ will in practice be horribly and user-visibly broken by this proposal. AFAICS, all the common use cases today will still work well with this proposal. ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 22:12 ` Johan Herland @ 2011-02-07 0:07 ` Dmitry Potapov 2011-02-07 19:05 ` Bernhard R. Link [not found] ` <201102070429.05033.johan@herland.net> 0 siblings, 2 replies; 104+ messages in thread From: Dmitry Potapov @ 2011-02-07 0:07 UTC (permalink / raw) To: Johan Herland Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Sun, Feb 06, 2011 at 11:12:51PM +0100, Johan Herland wrote: > > Yes, technically git 1.7.4 is a myth. However, by convention, we all agree > what "v1.7.4" points to, and nobody seriously believe they can get away with > pointing "v1.7.4" somewhere else. There are two sorts of tags: - local tags, which are never intended to be shared with others but used by users to mark some points in the working repository. - global tags, which are just _social_convention_ about what the current project considers as official versions. Without social convention, they make no sense. > The core of this discussion is where we want to place Git in the space > between "technically correct" and "socially conventional", where the former > means owning up to the fact that each repo really is its own namespace, and > there's no way around that in a proper DVCS, and the latter means building > social convention into our tools, thereby making it harder to deal with the > few unconventional cases (like my two semi-related repos case). Tags like words are social convention, which are used for communication between people participated in a project. But accordingly to you, it seems somehow "technically correct" to invent their own words in Humpty Dumpty's ways: 'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.' I am afraid you got the wrong idea about "proper DVCS", because DVCS does not imply that there is no social convention. It just means that there is no single authority that dictates everything. Like with words, there is no single authority that assigns meaning to new words, but that does not mean that you cannot just say "When I use a word... " if you want to be understood by others. > > AFAICS, my proposal does not harm the common case (unambiguous tags are > still interpreted unambiguously, even if they may exist in multiple > namespaces), while it _does_ help the uncommon case (by allowing ambiguous > tags to co-exist in the same repo). It hurts the common case in a few ways: 1. It breaks existing user scripts 2. It complicates things for users (as Matthieu wrote above). 3. git fetch cannot report a tag clash if it happens > > Granted, if we leave all tags in a single namespace, I can still work around > this by manually futzing with the configured refspecs to create ad hoc > namespaces. But I _really_ hate it when I'm forced to hack around the tool, > because the tool thinks it "knows better". I believe that the right interface when the common case is simple, but an uncommon case is still possible to handle. I don't think that currently git meets this criterion, but making tag namespaces based on the remote name strikes me as a really bad idea. Tags are attributes of a project and not particular remote. > > > But, IMHO, it is a myth that having different > > namespaces solves the problem, because in _most_ cases, you really want > > to have a single namespace _semantically_, so you can communicate with > > other people using this tag name. > > My proposal tries very hard to present a single namespace _semantically_ to > the user in the common case (when tags are unambiguous). I'd even go as far > as proposing that "git tag -l" should by default list only a single > shortened tag name in the cases where there are multiple unambiguous > alternatives. IMHO, it is very confusing, especially for people whose script was suddenly broken by those namespaces. > > Alternatively, I'd suggest a compromise (already mentioned elsewhere in this > thread) where we add a config variable tags.preferredRemote (defaults to > "origin") which allows you to directly select which namespace you consider > official. You could even implement this as physically copying > refs/remotes/${tag.preferredRemote}/tags/* into refs/tags/*. It seems you do not understand the problem that I am trying to say all way along: there is more than one repo from which I fetch tags, and because they are belong to the same project, they should be in the same namespace. So, IMHO, the proper solution should be ability to specify the desired namespace for any remote repository, like this: remote.<name>.tagNameSpace = foo So, those who want to have many namespaces should be able to that easily, but forcing multiple namespaces on those who have a single namespace semantically is simple wrong. Not to mention that it breaks existing scripts for no good reason. > > > > In that case it would be wrong of gitk to display "v1.0". Instead it > > > should_ display a longer, unambiguous name, e.g. "origin/v1.0". > > > > But it is still ambiguous because my "origin" may be different from > > yours origin. It is only unambiguous when it look at it _locally_ but > > that makes it completely useless for communication with other people. > > One project should have only one version with the same tag regardless > > where it came from. > > Again, you are setting "technical correctness" up against "social > convention". Technically, _any_ ref name whatsoever is repo-specific and > "completely useless for communication with other people". The only thing we > can communicate unambiguously is SHA-1 object names. However, social > conventions compel us to name our refs unambiguously and to use common sense > when communicating, so that - in practice - everybody in the project knows > exactly what is meant by "v1.0". Public tags are purely social convention. If there is no convention, they are completely meaningless, and we can use only SHA-1. Thus speaking about technical correctness of tags makes no sense. Dmitry ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 0:07 ` Dmitry Potapov @ 2011-02-07 19:05 ` Bernhard R. Link 2011-02-08 1:20 ` Dmitry Potapov [not found] ` <201102070429.05033.johan@herland.net> 1 sibling, 1 reply; 104+ messages in thread From: Bernhard R. Link @ 2011-02-07 19:05 UTC (permalink / raw) To: Dmitry Potapov Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre, Johan Herland * Dmitry Potapov <dpotapov@gmail.com> [110207 01:07]: > There are two sorts of tags: > - local tags, which are never intended to be shared with others but used > by users to mark some points in the working repository. > - global tags, which are just _social_convention_ about what the current > project considers as official versions. Without social convention, they > make no sense. >[...] > It seems you do not understand the problem that I am trying to say all > way along: there is more than one repo from which I fetch tags, and > because they are belong to the same project, they should be in the same > namespace. So there are those "local tags", which are not to be shared with others. Does that mean an user should always have two repositories, one with those tags for themselves and one without those tags for each other? And the private one should always be the one that does the push and fetch (as issuing a a fetch in the public to get something from the private will also get all those tags)? > > Granted, if we leave all tags in a single namespace, I can still work around > > this by manually futzing with the configured refspecs to create ad hoc > > namespaces. But I _really_ hate it when I'm forced to hack around the tool, > > because the tool thinks it "knows better". > > I believe that the right interface when the common case is simple, but > an uncommon case is still possible to handle. I don't think that > currently git meets this criterion, but making tag namespaces based on > the remote name strikes me as a really bad idea. Tags are attributes of > a project and not particular remote. Global tags are. Local tags are not. And even for global tags it can be interesting to see which remote has them, without having to manually look at all those remotes. > IMHO, it is very confusing, especially for people whose script was > suddenly broken by those namespaces. Like it was when remotes where introduced? > So, IMHO, the proper solution should be ability to specify the desired > namespace for any remote repository, like this: > > remote.<name>.tagNameSpace = foo > > So, those who want to have many namespaces should be able to that > easily, but forcing multiple namespaces on those who have a single > namespace semantically is simple wrong. Not to mention that it breaks > existing scripts for no good reason. I'd consider it more logical to have remote tags and a config to automatically make local copies of remote tags. (With whatever default people consider proper). Bernhard R. Link ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 19:05 ` Bernhard R. Link @ 2011-02-08 1:20 ` Dmitry Potapov 0 siblings, 0 replies; 104+ messages in thread From: Dmitry Potapov @ 2011-02-08 1:20 UTC (permalink / raw) To: Bernhard R. Link Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre, Johan Herland On Mon, Feb 07, 2011 at 08:05:51PM +0100, Bernhard R. Link wrote: > > So there are those "local tags", which are not to be shared with others. > Does that mean an user should always have two repositories, one with > those tags for themselves and one without those tags for each other? Well, I believe that the best practice is that each developer has his/her own private repo and there is also a "bare" repo to which is used to share results with others. In this way, local tags are stay only inside one's private repo. If you need to fetch directly from someone working repository, you can use "git fetch --no-tags", but obviously it is not an optimal solution if you also need to fetch global tags from it, because you will have to specify them explicitly. > > > Granted, if we leave all tags in a single namespace, I can still work around > > > this by manually futzing with the configured refspecs to create ad hoc > > > namespaces. But I _really_ hate it when I'm forced to hack around the tool, > > > because the tool thinks it "knows better". > > > > I believe that the right interface when the common case is simple, but > > an uncommon case is still possible to handle. I don't think that > > currently git meets this criterion, but making tag namespaces based on > > the remote name strikes me as a really bad idea. Tags are attributes of > > a project and not particular remote. > > Global tags are. Local tags are not. Sure. I probably should have said that I'd consider only global tags in the rest of my email, because local tags should not be normally visible outside of one's repo. > And even for global tags it can be interesting to see which remote has > them, without having to manually look at all those remotes. I am not sure why it should be interesting. I mean as long as you do not have tag clashes, you should not need to know that. And if you really need to know that, you can use "git ls-remote" to check actual references. > > > IMHO, it is very confusing, especially for people whose script was > > suddenly broken by those namespaces. > > Like it was when remotes where introduced? How many people used git back then and how many people are using now? Have you forgotten what happened when the dash was removed from git commands? There was endless cry about breaking git, though all what those people need to do is to add one directory to their PATH to have git dash commands back. So, what may be okay for a young and immature project (used by a small group of enthusiasts) may be not okay for a tool on which many people rely. Most people who use git now do not read ReleaseNotes. They just install a ready package for their favorite distro and expect everything to work as before. So, I think any changes should be introduced as gradual as possible. Dmitry ^ permalink raw reply [flat|nested] 104+ messages in thread
[parent not found: <201102070429.05033.johan@herland.net>]
* Re: [1.8.0] Provide proper remote ref namespaces [not found] ` <201102070429.05033.johan@herland.net> @ 2011-02-07 3:47 ` Nicolas Pitre 2011-02-08 1:06 ` Dmitry Potapov 1 sibling, 0 replies; 104+ messages in thread From: Nicolas Pitre @ 2011-02-07 3:47 UTC (permalink / raw) To: Johan Herland Cc: Dmitry Potapov, git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy On Mon, 7 Feb 2011, Johan Herland wrote: > In practice, this discussion boils down to whether we should use > > remote.origin.fetch = refs/tags/*:refs/remotes/origin/tags/* > or > remote.origin.fetch = refs/tags/*:refs/tags/* > > as the default refspec for tags. It clearly should be (and should have been from the start) the former one. > AFAICS, we both agree that whichever > refspec is chosen by default, it should be possible for the user to (fairly > easily) override, and use the other refspec instead. Indeed. And as you propose, the _usage_ of tags should largely be unchanged as in most cases there won't be any ambiguity, and therefore using "git log v1.7.0" will just work even if the v1.7.0 tag is actually refs/remotes/origin/tags/v1.7.0. So I hardly see what it is that people are unhappy about in this proposal. Nicolas ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces [not found] ` <201102070429.05033.johan@herland.net> 2011-02-07 3:47 ` Nicolas Pitre @ 2011-02-08 1:06 ` Dmitry Potapov 2011-02-08 8:15 ` Johan Herland 1 sibling, 1 reply; 104+ messages in thread From: Dmitry Potapov @ 2011-02-08 1:06 UTC (permalink / raw) To: Johan Herland Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Mon, Feb 07, 2011 at 04:29:04AM +0100, Johan Herland wrote: > > As I understand your view (I do apologize if I somehow misrepresent it), you > want Git to assume that the common practice of one semantic namespace is > followed. Furthermore, you also want to enforce that practice where > possible, while still improving the handling of the uncommon (but > theoretically inevitable) case (warning and presumably guiding the user when > a tag conflict occurs). Yes, you are correct. I consider a single tag namespace as the common case, but it should be possible to have more than one namespace for those who needs that. I think our disagreement is due to the fact that you believe that if someone added another remote, he or she wants another namespace for tags, but I think it depends on whether you treat different remotes as one project or different semi-related projects. There is a fundamental difference between branches and tags is that branches are often different (like each co-worker can publish each own master that he or she tested), but tags should have same tags as long as we work on the same project, otherwise it will lead to confusion. > > > 2. It complicates things for users (as Matthieu wrote above). > > I guess this depends on your POV. Fundamentally, I do NOT want to change how > people refer to tags. I only want to provide them the possibility of doing > so when ambiguity is present. IMHO, there are two fundamentally two different use cases: - one project with many remotes - two (probably semi-related) projects in the same repo In the first case, having two tags pointing to different commits is an obvious mistake that should be fixed as soon as possible. I do not think that different namespaces are necessary to fix that (or at least I do not see how it helps), but my main concern was that resolution of a tag conflict may be postponed (because they appear in different namespaces), but that does not resolve the confusion and may only prolong it. > > > 3. git fetch cannot report a tag clash if it happens > > Yes it can: For each tag fetched from the remote, if resolving its shorthand > name ("v1.7.4") results in ambiguity (i.e. there exists a conflicting tag > elsewhere in this repo), then warn the user about this conflict, and explain > how to refer to each tag candidate using the full ref name. Also explain how > the user may resolve the ambiguity by creating a local tag > ("refs/tags/v1.7.4") pointing to the preferred target. It it is possible then I do not have any serious objection here... > > So, IMHO, the proper solution should be ability to specify the desired > > namespace for any remote repository, like this: > > > > remote.<name>.tagNameSpace = foo > > Interesting. I'm not sure what "foo" means in this context. Would I use it > like this?: > > remote.origin.tagNameSpace = refs/tags I was not sure about the specific when I wrote this, so I just put "foo", but it could be something like you wrote above. > > (to place origin's tags in refs/tags/*) > > If so, what's the difference between this option, and using this?: > > remote.origin.fetch = refs/tags/*:refs/tags/* I have not tried that, but I suspect that it will cause that all tags will be fetched even if they are not belong to tracked branches, i.e. "git fetch" will work as "git fetch -t". But maybe I am wrong here. Dmitry ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-08 1:06 ` Dmitry Potapov @ 2011-02-08 8:15 ` Johan Herland 2011-02-08 19:11 ` Enrico Weigelt 2011-02-08 23:13 ` Junio C Hamano 0 siblings, 2 replies; 104+ messages in thread From: Johan Herland @ 2011-02-08 8:15 UTC (permalink / raw) To: Dmitry Potapov Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Tuesday 08 February 2011, Dmitry Potapov wrote: > On Mon, Feb 07, 2011 at 04:29:04AM +0100, Johan Herland wrote: > > > So, IMHO, the proper solution should be ability to specify the > > > desired namespace for any remote repository, like this: > > > > > > remote.<name>.tagNameSpace = foo > > > > Interesting. I'm not sure what "foo" means in this context. Would I use > > it > > > > like this?: > > remote.origin.tagNameSpace = refs/tags > > I was not sure about the specific when I wrote this, so I just put "foo", > but it could be something like you wrote above. > > > (to place origin's tags in refs/tags/*) > > > > If so, what's the difference between this option, and using this?: > > remote.origin.fetch = refs/tags/*:refs/tags/* > > I have not tried that, but I suspect that it will cause that all tags > will be fetched even if they are not belong to tracked branches, i.e. > "git fetch" will work as "git fetch -t". But maybe I am wrong here. Ah, yes, I should have been more specific: remote.origin.fetch = ~refs/tags/*:refs/tags/* In my proposal, I suggest using a "~" prefix to signal auto-following behavior. This is needed in order to be able to explicitly specify the current fetch behavior in the configuration. ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-08 8:15 ` Johan Herland @ 2011-02-08 19:11 ` Enrico Weigelt 2011-02-08 23:13 ` Junio C Hamano 1 sibling, 0 replies; 104+ messages in thread From: Enrico Weigelt @ 2011-02-08 19:11 UTC (permalink / raw) To: git * Johan Herland <johan@herland.net> wrote: > Ah, yes, I should have been more specific: > > remote.origin.fetch = ~refs/tags/*:refs/tags/* > > In my proposal, I suggest using a "~" prefix to signal auto-following > behavior. This is needed in order to be able to explicitly specify the > current fetch behavior in the configuration. Under the hood, this line could be automatically "added" (internally) unless some "fetch.autotag = false" is given. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-08 8:15 ` Johan Herland 2011-02-08 19:11 ` Enrico Weigelt @ 2011-02-08 23:13 ` Junio C Hamano 2011-02-09 1:24 ` Johan Herland 1 sibling, 1 reply; 104+ messages in thread From: Junio C Hamano @ 2011-02-08 23:13 UTC (permalink / raw) To: Johan Herland Cc: Dmitry Potapov, git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: > Ah, yes, I should have been more specific: > > remote.origin.fetch = ~refs/tags/*:refs/tags/* Hmmm, I was in the vicinity of builtin/fetch.c:find_non_local_tags() today, and I had to wonder what the implementation of this would look like.... ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-08 23:13 ` Junio C Hamano @ 2011-02-09 1:24 ` Johan Herland 0 siblings, 0 replies; 104+ messages in thread From: Johan Herland @ 2011-02-09 1:24 UTC (permalink / raw) To: Junio C Hamano Cc: Dmitry Potapov, git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Wednesday 09 February 2011, Junio C Hamano wrote: > Johan Herland <johan@herland.net> writes: > > Ah, yes, I should have been more specific: > > remote.origin.fetch = ~refs/tags/*:refs/tags/* > > Hmmm, I was in the vicinity of builtin/fetch.c:find_non_local_tags() > today, and I had to wonder what the implementation of this would look > like.... AFAIK, find_non_local_tags() is called to produce a list of refs to be auto- followed. Currently it produces this list by traversing the remote refs, and selecting refs that follow all of these criteria: A. Ref name starts with "refs/tags" B. Ref refers (after peeling) to an object that is either already locally available, or is already on the list of objects to be fetched. C. Ref name does not already exist locally. Now, here's roughly how I would change it to implement the "~from:to"-style refspecs: 0. Change its name from find_non_local_tags() to find_auto_follow_refs(). 1. At the top, enumerate the auto-following refspecs ("~refs/tags/*:refs/tags/*" in this case) 2. When traversing the remote refs, instead of criteria A above, we want to check if ref->name matches the remote side of any of the auto-following refspecs enumerated in step #1. Skip past all non-matches. 3. Criteria B stays unchanged. 4. When checking criteria C, we want to check against the _local_ side of the matched auto-following refspec. AFAICS, that's pretty much what should be needed. There are some other things to consider as well, but IMHO none of those seem like show stoppers: For example, there may be command-line options for making auto-following refspecs explicit (i.e. corresponding to --tags; basically disables the "~" in the refspec), or disabling auto-following (i.e. corresponding to --no- tags; basically disregards refspecs with "~"). Another slight complication is refspecs with _both_ "~" and "+" (i.e. both auto-following and --force behavior), which may be resolved by disregarding criteria C for those refspecs. Have fun! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 0:04 ` Johan Herland 2011-02-06 12:03 ` Dmitry Potapov @ 2011-02-06 20:28 ` Matthieu Moy 2011-02-06 23:22 ` Johan Herland 1 sibling, 1 reply; 104+ messages in thread From: Matthieu Moy @ 2011-02-06 20:28 UTC (permalink / raw) To: Johan Herland Cc: Dmitry Potapov, git, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: > I don't see how the separate namespaces cause problems here. Also, I don't > know what you're proposing instead, or indeed what other organization of > tags would lead to less confusion. I'm not against the idea, but one drawback of the separate namespace is that it introduces complexity for the user. In the common case, where the user may fetch the same tag from various sources, there will still be several refs (probably listed by "git tag" ?), and this may confuse the user. Another question is what happens when you push. With branches, fetching XXX fetches in origin/XXX, but pushing YYY does push to YYY. This asymetry between push and pull works well because most of the time, if we have a origin/XXX branch, we also have XXX (with origin/XXX as upstream). For tags, it's clearly different. If I have origin/v1.7.4, I don't see much reason to have _also_ v1.7.4 as a local tag. And if I have only origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from it will get origin/origin/v1.7.4, and so on. So, my feeling is that the "separate namespace" should not be automatic. For example, today, git.git repo contains tags like v1.7.4 and others like gitgui-0.13.0, which is clearly a handmade namespace, where a real namespace would be better. That would make a lot of sence to me if Junio had something like [remote "git-gui"] url = ... fetch = +refs/heads/*:refs/remotes/git-gui/* fetch = +refs/tags/*:refs/tags/remotes/git-gui/* or whatever other syntax, so that git-gui's tags be automatically fetched into the right namespace (with no warning in case of duplicate). But OTOH, I don't want to have several namespaces in my git repo even if I configure several remotes to fetch from. In this case, duplicate tags are just redundancy if they point to the same object, and a real conflict I want to know about immediately otherwise. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 20:28 ` Matthieu Moy @ 2011-02-06 23:22 ` Johan Herland 2011-02-06 23:51 ` Matthieu Moy 2011-02-07 0:14 ` Dmitry Potapov 0 siblings, 2 replies; 104+ messages in thread From: Johan Herland @ 2011-02-06 23:22 UTC (permalink / raw) To: git Cc: Matthieu Moy, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre (resend without HTML part; I apologize for the inconvenience) On Sunday 06 February 2011, Matthieu Moy wrote: > Johan Herland <johan@herland.net> writes: > > I don't see how the separate namespaces cause problems here. Also, I > > don't know what you're proposing instead, or indeed what other > > organization of tags would lead to less confusion. > > I'm not against the idea, but one drawback of the separate namespace > is that it introduces complexity for the user. In the common case, > where the user may fetch the same tag from various sources, there > will still be several refs (probably listed by "git tag" ?), and this > may confuse the user. If the user is confused by putting remote tags in separate namespaces, then the user is likely also confused by the current practice of putting remote _branches_ in separate namespaces. My point is that by strictly delineating the boundaries between what is local and what belongs to a given remote, I hope we could help some newbies past the local vs. remote confusion that often manifests itself when migrating from a centralized VCS to a DVCS. > Another question is what happens when you push. With branches, > fetching XXX fetches in origin/XXX, but pushing YYY does push to YYY. > This asymetry between push and pull works well because most of the > time, if we have a origin/XXX branch, we also have XXX (with > origin/XXX as upstream). I look at it differently: "fetch" is for information discovery (i.e. "I want to know what's happened on the remote"), while pull/push is about making real changes to local/remote branches. > For tags, it's clearly different. If I have origin/v1.7.4, I don't see > much reason to have _also_ v1.7.4 as a local tag. And if I have only > origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from > it will get origin/origin/v1.7.4, and so on. Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in the origin remote, so there's no point in trying to push it back. On the other hand, if you have v1.7.4 locally (but not origin/v1.7.4), you should (assuming this is intended to be a public tag) consider pushing it to the "origin" remote, thus causing origin/v1.7.4 to appear in your repo. > So, my feeling is that the "separate namespace" should not be > automatic. > > For example, today, git.git repo contains tags like v1.7.4 and others > like gitgui-0.13.0, which is clearly a handmade namespace, where a > real namespace would be better. That would make a lot of sence to me > if Junio had something like > > [remote "git-gui"] > url = ... > fetch = +refs/heads/*:refs/remotes/git-gui/* > fetch = +refs/tags/*:refs/tags/remotes/git-gui/* > > or whatever other syntax, so that git-gui's tags be automatically > fetched into the right namespace (with no warning in case of > duplicate). > > But OTOH, I don't want to have several namespaces in my git repo even > if I configure several remotes to fetch from. In this case, duplicate > tags are just redundancy if they point to the same object, and a real > conflict I want to know about immediately otherwise. As Nicolas mentioned elsewhere in the thread, having separate tag namespaces does not prevent us from also warning about ambiguous tag names on fetch. With separate namespaces, you could probably implement such a warning more easily as a hook, instead of hacking the fetch code directly. ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 23:22 ` Johan Herland @ 2011-02-06 23:51 ` Matthieu Moy 2011-02-07 3:51 ` Johan Herland 2011-02-07 0:14 ` Dmitry Potapov 1 sibling, 1 reply; 104+ messages in thread From: Matthieu Moy @ 2011-02-06 23:51 UTC (permalink / raw) To: Johan Herland Cc: git, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: >> For tags, it's clearly different. If I have origin/v1.7.4, I don't see >> much reason to have _also_ v1.7.4 as a local tag. And if I have only >> origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from >> it will get origin/origin/v1.7.4, and so on. > > Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in the > origin remote, so there's no point in trying to push it back. On the other > hand, if you have v1.7.4 locally (but not origin/v1.7.4), you should > (assuming this is intended to be a public tag) consider pushing it to the > "origin" remote, thus causing origin/v1.7.4 to appear in your repo. (I made a bad choice by repeating "origin" several times) What happens if I pull from "remoteA" and then push to "remoteB"? With branches, I'd create a local "master" from remoteA/master, and then push my local "master" as "master" on remoteB. People looking at my repository remoteB won't notice where it's comming from because it had to be local for me at some point. With tags, we probably don't want to force people to explicitely create local tags to be able to push them. Take the example of the interim maintainer cited somewhere else in this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4 tag, and on my side, I do not want to end up having shawn/junio/v1.7.4, especially if this means that people fetching from me would end up with a me/shawn/junio/v1.7.4 ... > As Nicolas mentioned elsewhere in the thread, having separate tag namespaces > does not prevent us from also warning about ambiguous tag names on > fetch. It does not "prevent", but I think it makes it a mis-feature. Distinct namespaces (as opposed to warning/errors on duplicate at fetch time) are useful when the same short name can refer to several things (like v1.7.4 Vs gitgui-v1.7.4 (which doesn't exist yet), and then it's not a problem to have twice the same short name. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 23:51 ` Matthieu Moy @ 2011-02-07 3:51 ` Johan Herland 2011-02-07 5:11 ` Jeff King 2011-02-07 6:54 ` Matthieu Moy 0 siblings, 2 replies; 104+ messages in thread From: Johan Herland @ 2011-02-07 3:51 UTC (permalink / raw) To: Matthieu Moy Cc: git, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Monday 07 February 2011, Matthieu Moy wrote: > Johan Herland <johan@herland.net> writes: > >> For tags, it's clearly different. If I have origin/v1.7.4, I don't see > >> much reason to have _also_ v1.7.4 as a local tag. And if I have only > >> origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from > >> it will get origin/origin/v1.7.4, and so on. > > > > Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in > > the origin remote, so there's no point in trying to push it back. On > > the other hand, if you have v1.7.4 locally (but not origin/v1.7.4), > > you should (assuming this is intended to be a public tag) consider > > pushing it to the "origin" remote, thus causing origin/v1.7.4 to > > appear in your repo. > > (I made a bad choice by repeating "origin" several times) > > What happens if I pull from "remoteA" and then push to "remoteB"? So, when you pull from "remoteA", you get "refs/remotes/remoteA/tags/v1.7.4", but since it is unambiguous, you can refer to it by "v1.7.4" instead. When you push to "remoteB", you would say "git push remoteB tag v1.7.4", and it would resolve "v1.7.4" (via "refs/remotes/remoteA/tags/v1.7.4") into the appropriate SHA-1, and then push the "v1.7.4" tag to the remote. You have to separate the namespace from the name itself. For instance, if I run "git push remoteB tag v1.7.4", it resolves "v1.7.4" into refs/tags/v1.7.4, but that doesn't mean that I end up with "refs/tags/refs/tags/v1.7.4" in the "remoteB" repo. > Take the example of the interim maintainer cited somewhere else in > this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4 > tag, and on my side, I do not want to end up having > shawn/junio/v1.7.4, especially if this means that people fetching from > me would end up with a me/shawn/junio/v1.7.4 ... You won't end up with "shawn/junio/v1.7.4". When Shawn fetches from Junio, what he actually gets is "refs/remotes/junio/tags/v1.7.4" ("junio/v1.7.4" is a shorthand; "v1.7.4" is an even better shorthand). Next, you should never pull from Shawn's work repo, but rather from the repo he has published. In that repo he will typically have pushed the "v1.7.4" tag (as described above). When you pull from Shawn's public repo, you will get the "v1.7.4" tag at "refs/remotes/shawn/tags/v1.7.4" (but "v1.7.4" is an unambigious shorthand). Even if you _were_ to pull directly from Shawn's work repo, you would not get the "shawn/junio/v1.7.4" mess you fear, simply because when you fetch from a repo, the refs inside that repo's "refs/remotes" are not fetched. ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 3:51 ` Johan Herland @ 2011-02-07 5:11 ` Jeff King 2011-02-07 8:58 ` Johan Herland 2011-02-07 6:54 ` Matthieu Moy 1 sibling, 1 reply; 104+ messages in thread From: Jeff King @ 2011-02-07 5:11 UTC (permalink / raw) To: Johan Herland Cc: Matthieu Moy, git, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Mon, Feb 07, 2011 at 04:51:37AM +0100, Johan Herland wrote: > > Take the example of the interim maintainer cited somewhere else in > > this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4 > > tag, and on my side, I do not want to end up having > > shawn/junio/v1.7.4, especially if this means that people fetching from > > me would end up with a me/shawn/junio/v1.7.4 ... > > You won't end up with "shawn/junio/v1.7.4". When Shawn fetches from Junio, > what he actually gets is "refs/remotes/junio/tags/v1.7.4" ("junio/v1.7.4" is > a shorthand; "v1.7.4" is an even better shorthand). But keep in mind that this proposal will have to live alongside repos that are using older versions of git. So Shawn might very well have refs/tags/v1.7.4 from Junio if he is using (or has ever used) pre-1.8.0 git. No, that won't give you me/shawn/junio/v1.7.4, but it does mean we have to gracefully handle the case of ambiguous duplicate tags (that happen to point to the same thing). Which I think you are implying here: > Next, you should never pull from Shawn's work repo, but rather from the repo > he has published. In that repo he will typically have pushed the "v1.7.4" > tag (as described above). When you pull from Shawn's public repo, you will > get the "v1.7.4" tag at "refs/remotes/shawn/tags/v1.7.4" (but "v1.7.4" is an > unambigious shorthand). But I wanted to point it out explicitly. -Peff ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 5:11 ` Jeff King @ 2011-02-07 8:58 ` Johan Herland 2011-02-07 9:01 ` Sverre Rabbelier 2011-02-07 20:19 ` Jeff King 0 siblings, 2 replies; 104+ messages in thread From: Johan Herland @ 2011-02-07 8:58 UTC (permalink / raw) To: Jeff King Cc: git, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Monday 07 February 2011, Jeff King wrote: > On Mon, Feb 07, 2011 at 04:51:37AM +0100, Johan Herland wrote: > > > Take the example of the interim maintainer cited somewhere else in > > > this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4 > > > tag, and on my side, I do not want to end up having > > > shawn/junio/v1.7.4, especially if this means that people fetching > > > from me would end up with a me/shawn/junio/v1.7.4 ... > > > > You won't end up with "shawn/junio/v1.7.4". When Shawn fetches from > > Junio, what he actually gets is "refs/remotes/junio/tags/v1.7.4" > > ("junio/v1.7.4" is a shorthand; "v1.7.4" is an even better shorthand). > > But keep in mind that this proposal will have to live alongside repos > that are using older versions of git. So Shawn might very well have > refs/tags/v1.7.4 from Junio if he is using (or has ever used) pre-1.8.0 > git. Yes, but since they point to the same object, there's no ambiguity. I'm also starting to wonder whether we should, in existing repos with existing remotes, keep using the old-style refspecs by default, thereby making new-style refspecs the default only for _new_ repos. It seems mixing the two styles in one repo would cause confusion. Another alternative would be to transform old-style remotes into new-style remotes, but I believe that was shot down elsewhere in this thread. > No, that won't give you me/shawn/junio/v1.7.4, but it does mean we have > to gracefully handle the case of ambiguous duplicate tags (that happen > to point to the same thing). Whoa, we use the "ambiguous" term differently here. In this whole thread I have used "ambiguous" exclusively about when the same (shorthand) tag name point to _different_ things. As long as they point to the same thing, there is no ambiguity, IMHO. > Which I think you are implying here: > > Next, you should never pull from Shawn's work repo, but rather from the > > repo he has published. In that repo he will typically have pushed the > > "v1.7.4" tag (as described above). When you pull from Shawn's public > > repo, you will get the "v1.7.4" tag at > > "refs/remotes/shawn/tags/v1.7.4" (but "v1.7.4" is an unambigious > > shorthand). > > But I wanted to point it out explicitly. Yes, over its lifetime a tag name ("v1.7.4") might appear in several namespaces (refs/tags, refs/remotes/*/tags), but it's always identifiable with the shorthand "v1.7.4" name (assuming no other "v1.7.4" name point to a different object). This is the same technique we use when talking about branch names: On this mailing list, nobody is confused when I refer to 'maint', 'master', 'next' and 'pu'. Still, in our own work repos (at least in mine), these branches are actually called "refs/remotes/origin/<name>" (commonly referred to by their shorthands "origin/<name>"). Here we are, juggling the same kind of namespaces that I propose for tags, and it seems to work well without causing much confusion. ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 8:58 ` Johan Herland @ 2011-02-07 9:01 ` Sverre Rabbelier 2011-02-07 10:06 ` Johan Herland 2011-02-07 20:19 ` Jeff King 1 sibling, 1 reply; 104+ messages in thread From: Sverre Rabbelier @ 2011-02-07 9:01 UTC (permalink / raw) To: Johan Herland Cc: Jeff King, git, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Nguyen Thai Ngoc Duy, Nicolas Pitre Heya, On Mon, Feb 7, 2011 at 09:58, Johan Herland <johan@herland.net> wrote: > This is the same technique we use when talking about branch names: On this > mailing list, nobody is confused when I refer to 'maint', 'master', 'next' > and 'pu'. Still, in our own work repos (at least in mine), these branches > are actually called "refs/remotes/origin/<name>" (commonly referred to by > their shorthands "origin/<name>"). Here we are, juggling the same kind of > namespaces that I propose for tags, and it seems to work well without > causing much confusion. With the difference that you can't refer to "maint" as just "maint" unless you've created "refs/heads/maint" iff it is unambiguous. -- Cheers, Sverre Rabbelier ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 9:01 ` Sverre Rabbelier @ 2011-02-07 10:06 ` Johan Herland 2011-02-07 10:22 ` Nguyen Thai Ngoc Duy 0 siblings, 1 reply; 104+ messages in thread From: Johan Herland @ 2011-02-07 10:06 UTC (permalink / raw) To: Sverre Rabbelier Cc: Jeff King, git, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Nguyen Thai Ngoc Duy, Nicolas Pitre On Monday 07 February 2011, Sverre Rabbelier wrote: > On Mon, Feb 7, 2011 at 09:58, Johan Herland <johan@herland.net> wrote: > > This is the same technique we use when talking about branch names: > > On this mailing list, nobody is confused when I refer to 'maint', > > 'master', 'next' and 'pu'. Still, in our own work repos (at least > > in mine), these branches are actually called > > "refs/remotes/origin/<name>" (commonly referred to by their > > shorthands "origin/<name>"). Here we are, juggling the same kind of > > namespaces that I propose for tags, and it seems to work well > > without causing much confusion. > > With the difference that you can't refer to "maint" as just "maint" > unless you've created "refs/heads/maint" iff it is unambiguous. Except that with 'git checkout', you can: $ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git/ $ git checkout maint ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 10:06 ` Johan Herland @ 2011-02-07 10:22 ` Nguyen Thai Ngoc Duy 0 siblings, 0 replies; 104+ messages in thread From: Nguyen Thai Ngoc Duy @ 2011-02-07 10:22 UTC (permalink / raw) To: Johan Herland Cc: Sverre Rabbelier, Jeff King, git, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Nicolas Pitre On Mon, Feb 7, 2011 at 5:06 PM, Johan Herland <johan@herland.net> wrote: > On Monday 07 February 2011, Sverre Rabbelier wrote: >> On Mon, Feb 7, 2011 at 09:58, Johan Herland <johan@herland.net> wrote: >> > This is the same technique we use when talking about branch names: >> > On this mailing list, nobody is confused when I refer to 'maint', >> > 'master', 'next' and 'pu'. Still, in our own work repos (at least >> > in mine), these branches are actually called >> > "refs/remotes/origin/<name>" (commonly referred to by their >> > shorthands "origin/<name>"). Here we are, juggling the same kind of >> > namespaces that I propose for tags, and it seems to work well >> > without causing much confusion. >> >> With the difference that you can't refer to "maint" as just "maint" >> unless you've created "refs/heads/maint" iff it is unambiguous. > > Except that with 'git checkout', you can: > > $ git clone git://git.kernel.org/pub/scm/git/git.git > $ cd git/ > $ git checkout maint That's some checkout magic kicking in. I cloned and there was only refs/heads/master. After checkout, refs/heads/maint appeared. $ git clone git://git.kernel.org/pub/scm/git/git.git git2 $ cd git2 $ git rev-parse maint maint fatal: ambiguous argument 'maint': unknown revision or path not in the working tree. Use '--' to separate paths from revisions $ git rev-parse origin/maint 597a63054241c122515c93cbce45bc44eb231f18 $ git co maint Branch maint set up to track remote branch maint from origin. Switched to a new branch 'maint' $ git rev-parse maint 597a63054241c122515c93cbce45bc44eb231f18 -- Duy ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 8:58 ` Johan Herland 2011-02-07 9:01 ` Sverre Rabbelier @ 2011-02-07 20:19 ` Jeff King 2011-02-08 0:59 ` Johan Herland 1 sibling, 1 reply; 104+ messages in thread From: Jeff King @ 2011-02-07 20:19 UTC (permalink / raw) To: Johan Herland Cc: git, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote: > > No, that won't give you me/shawn/junio/v1.7.4, but it does mean we have > > to gracefully handle the case of ambiguous duplicate tags (that happen > > to point to the same thing). > > Whoa, we use the "ambiguous" term differently here. In this whole thread I > have used "ambiguous" exclusively about when the same (shorthand) tag name > point to _different_ things. As long as they point to the same thing, there > is no ambiguity, IMHO. Sorry, I should have been more clear. I meant "ambiguous by the current code's definition", meaning "we would still need to use your new ambiguity definition to resolve this situation". IOW, I think we are on the same page. > This is the same technique we use when talking about branch names: On this > mailing list, nobody is confused when I refer to 'maint', 'master', 'next' > and 'pu'. Still, in our own work repos (at least in mine), these branches > are actually called "refs/remotes/origin/<name>" (commonly referred to by > their shorthands "origin/<name>"). Here we are, juggling the same kind of > namespaces that I propose for tags, and it seems to work well without > causing much confusion. Just playing devil's advocate for a moment: isn't this namespace distinction one of the more confusing things in git for new users? That is, I have seen new-ish git users say "OK, so I cloned from upstream. How come I can't say "git log maint" now?" Or it used to be "how come I can't "git checkout maint" now?" The latter is now handled by some very specific magic in "git checkout", but in general ref lookup does not automagically look in remotes namespaces, and it has caused some confusion. So here we are introducing more distinction between project-wide names and per-remote names. I absolutely think it's the right thing to do from a "keep it simple, orthogonal, and distributed" perspective. But we also need to recognize we are making some common use cases more confusing. In the case of remote-tracking branches, we ended up adding some porcelain features to make common actions (like checking out a local branch from a remote) more seamless. But there is still some confusion among new users. I'm sort of rambling as I'm not quite sure yet what this means for the tags proposal, but a few questions I think are important to consider are: 1. Where have we succeeded and where have we failed with making separate-remotes / tracking branches seamless to the user (as opposed to something like a system where fetching from upstream fetches straight into your master branch (which has its own problems, but would be conceptually very simple)? Do those failures apply in this case, and if so how can we do better? 2. Can we apply new ideas for handling separate-remote tags to the branches case? Obviously one big proposal is searching in the per-remote tag namespace for refs. Should we be doing the same with heads? -Peff ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 20:19 ` Jeff King @ 2011-02-08 0:59 ` Johan Herland 2011-02-11 15:13 ` Jakub Narebski 0 siblings, 1 reply; 104+ messages in thread From: Johan Herland @ 2011-02-08 0:59 UTC (permalink / raw) To: Jeff King Cc: git, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Monday 07 February 2011, Jeff King wrote: > On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote: > > This is the same technique we use when talking about branch names: On > > this mailing list, nobody is confused when I refer to 'maint', > > 'master', 'next' and 'pu'. Still, in our own work repos (at least in > > mine), these branches are actually called "refs/remotes/origin/<name>" > > (commonly referred to by their shorthands "origin/<name>"). Here we > > are, juggling the same kind of namespaces that I propose for tags, and > > it seems to work well without causing much confusion. > > Just playing devil's advocate for a moment: isn't this namespace > distinction one of the more confusing things in git for new users? That > is, I have seen new-ish git users say "OK, so I cloned from upstream. > How come I can't say "git log maint" now?" Or it used to be "how come I > can't "git checkout maint" now?" The latter is now handled by some very > specific magic in "git checkout", but in general ref lookup does not > automagically look in remotes namespaces, and it has caused some > confusion. > > So here we are introducing more distinction between project-wide names > and per-remote names. I absolutely think it's the right thing to do from > a "keep it simple, orthogonal, and distributed" perspective. But we also > need to recognize we are making some common use cases more confusing. In > the case of remote-tracking branches, we ended up adding some porcelain > features to make common actions (like checking out a local branch from a > remote) more seamless. But there is still some confusion among new > users. > > I'm sort of rambling as I'm not quite sure yet what this means for the > tags proposal, but a few questions I think are important to consider > are: > > 1. Where have we succeeded and where have we failed with making > separate-remotes / tracking branches seamless to the user (as > opposed to something like a system where > fetching from upstream fetches straight into your master branch > (which has its own problems, but would be conceptually very > simple)? Do those failures apply in this case, and if so how can we > do better? > > 2. Can we apply new ideas for handling separate-remote tags to the > branches case? Obviously one big proposal is searching in the > per-remote tag namespace for refs. Should we be doing the same with > heads? I pretty much completely agree with your train of thought. First, although the separate-remotes may at first be confusing to newbies coming from a centralized VCS, I don't think this is the _main_ source of confusion. And, as you imply, we cannot eliminate this kind of conceptual confusion in any case, without violating core DVCS principles (like Bazaar does in its "centralized workflow"). The best way to address this is, as you say, by keeping it "simple, orthogonal, and distributed" (and try very hard to keep the common use cases minimally affected). We should instead look at what other (and preferrable fixable) sources of confusion we have in this area. Answering Git questions from colleagues at $dayjob, they often describe how they tried to accomplish something in Git, and I sometimes find myself giving a reply of the following form: "Yes, what you tried does make sense from your POV, but in this situation Git actually does this other thing instead, so instead you have to do ...". I don't like giving answers like this, because I get this nagging feeling that the problem is Git's fault, and not the user's. So, to enumerate some of these inconsistencies (I'm sure there are more that I cannot recall, right now): - Lack of consistency in the ref namespace (refs/remotes/$remote/* vs. refs/tags/*). Also not clear from the current layout where to add new types of refs (e.g. notes, replace). My proposal tries to address this issue. - Lack of consistency in which fetch refspecs must be listed in the configuration. (i.e. implicit vs. explicit fetch refspecs). My proposal tries to address this as well. - Lack of consistency in porcelain interfaces. Some of these have been fixed in recent Git version, but some are yet to be fixed: E.g. some find the use of FETCH_HEAD confusing (when does fetch update the remote refs, and when does it update FETCH_HEAD instead?). Others (myself included) wonder why 'git push' by default updates remote branches with matching names, while 'git pull' relies on the explicitly configured upstreams to update the local refs. (FWIW, I've mitigated this last complaint insisting that all users at $dayjob run "git config --global push.default tracking" immediately after installing Git.) There are other UI inconsistencies too that escape me ATM. When it comes to your second question, I believe it's definitely worth looking closer at whether we can exploit unambiguity across namespaces for all types of refs (not just tags). I expect there are some non-trivial issues down that road (some of these being discussed elsewhere in this thread), but we may still end up with something better. Thanks for the feedback! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-08 0:59 ` Johan Herland @ 2011-02-11 15:13 ` Jakub Narebski 2011-02-13 23:36 ` Johan Herland 0 siblings, 1 reply; 104+ messages in thread From: Jakub Narebski @ 2011-02-11 15:13 UTC (permalink / raw) To: Johan Herland Cc: Jeff King, git, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: > On Monday 07 February 2011, Jeff King wrote: > > On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote: > > > This is the same technique we use when talking about branch names: On > > > this mailing list, nobody is confused when I refer to 'maint', > > > 'master', 'next' and 'pu'. Still, in our own work repos (at least in > > > mine), these branches are actually called "refs/remotes/origin/<name>" > > > (commonly referred to by their shorthands "origin/<name>"). Here we > > > are, juggling the same kind of namespaces that I propose for tags, and > > > it seems to work well without causing much confusion. > > > > Just playing devil's advocate for a moment: isn't this namespace > > distinction one of the more confusing things in git for new users? That > > is, I have seen new-ish git users say "OK, so I cloned from upstream. > > How come I can't say "git log maint" now?" Or "where are all the branches?" ('git branch' doesn't show remote-tracking branches). > > Or it used to be "how come I can't "git checkout maint" now?" The > > latter is now handled by some very specific magic in "git > > checkout", but in general ref lookup does not automagically look > > in remotes namespaces, and it has caused some confusion. One has to be very careful with DWIM-mery, lest it would increase confusion instead of reducing it. [...] > First, although the separate-remotes may at first be confusing to newbies > coming from a centralized VCS, I don't think this is the _main_ source of > confusion. And, as you imply, we cannot eliminate this kind of conceptual > confusion in any case, without violating core DVCS principles (like Bazaar > does in its "centralized workflow"). The best way to address this is, as you > say, by keeping it "simple, orthogonal, and distributed" (and try very hard > to keep the common use cases minimally affected). Well, I think the confusion was greater and more dangerous in pre-separate remotes era ('master' mapped to 'origin', branches mapped to themselves, for single 'origin' remote). > - Lack of consistency in the ref namespace (refs/remotes/$remote/* vs. > refs/tags/*). Also not clear from the current layout where to add new types > of refs (e.g. notes, replace). My proposal tries to address this issue. The lack of consistency is there because tags should USUALLY be global (there should be only one v1.7.4), while branch names should be local (my 'master' branch is not your 'master' branch). In some cases, like joining or subtree-merging unrelated projects we would want local / per-remote tags: 'v1.7.4' in main project is not 'v1.7.4' in 'foo' subproject (in 'foo' remote). Currently we lack a way to specify that (the 'autofollow' refspec proposal, default behaviour would be equivalent to '~refs/tags/*:refs/tags/*"), and lack support from porcelain: MY PROPOSAL is to add '--use-separate-tags' (like old '--use-separate-remote') to "git clone" and "git remote add", and perhaps '--alternate' as equivalent to '--no-separate-tags' to "git remote add". > - Lack of consistency in which fetch refspecs must be listed in the > configuration. (i.e. implicit vs. explicit fetch refspecs). My proposal > tries to address this as well. Could you repeat your proposal? Do I remember it correctly that with 'autofollow' refspec (valid only for tags... well, perhaps also for notes and replacements) you want to specify defaults in config explicitely [remote "origin"] url = git://git.example.com/repo.git fetch = +refs/heads/*:refs/remotes/origin/* fetch = ~refs/tags/*:refs/tags/* Perhaps with fetch = +refs/heads/*:refs/remotes/origin/heads/* > > - Lack of consistency in porcelain interfaces. Some of these have been fixed > in recent Git version, but some are yet to be fixed: E.g. some find the use > of FETCH_HEAD confusing (when does fetch update the remote refs, and when > does it update FETCH_HEAD instead?). One of problems is how to keep the fact that $ git pull <URL> <branch> does one-off pull without creating remote or remote-tracking branch. But I agree that behavior of $ git pull <remote> <branch> can be confusing. > Others (myself included) wonder why 'git push' by default updates > remote branches with matching names, while 'git pull' relies on the > explicitly configured upstreams to update the local refs. (FWIW, > I've mitigated this last complaint insisting that all users at > $dayjob run "git config --global push.default tracking" immediately > after installing Git.) There are other UI inconsistencies too that > escape me ATM. IMHO that's not inconsisnency in Git, this is just reflection of the fact that in most common case the situation is *assymetric* with respect to fetch and push; you fetch from other people repositories, but you push to (usually single, perhaps mirrored) your own publishing repository. For this situation 'push.default = matching' works perfectly. > > When it comes to your second question, I believe it's definitely worth > looking closer at whether we can exploit unambiguity across namespaces for > all types of refs (not just tags). I expect there are some non-trivial > issues down that road (some of these being discussed elsewhere in this > thread), but we may still end up with something better. -- Jakub Narebski Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-11 15:13 ` Jakub Narebski @ 2011-02-13 23:36 ` Johan Herland 2011-02-14 7:35 ` Junio C Hamano 2011-02-14 9:40 ` [1.8.0] Provide proper remote ref namespaces Jakub Narebski 0 siblings, 2 replies; 104+ messages in thread From: Johan Herland @ 2011-02-13 23:36 UTC (permalink / raw) To: Jakub Narebski Cc: git, Jeff King, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Friday 11 February 2011, Jakub Narebski wrote: > Johan Herland <johan@herland.net> writes: > > - Lack of consistency in the ref namespace (refs/remotes/$remote/* vs. > > refs/tags/*). Also not clear from the current layout where to add new > > types of refs (e.g. notes, replace). My proposal tries to address this > > issue. > > The lack of consistency is there because tags should USUALLY be global > (there should be only one v1.7.4), while branch names should be local > (my 'master' branch is not your 'master' branch). > > In some cases, like joining or subtree-merging unrelated projects we > would want local / per-remote tags: 'v1.7.4' in main project is not > 'v1.7.4' in 'foo' subproject (in 'foo' remote). Currently we lack a > way to specify that (the 'autofollow' refspec proposal, default > behaviour would be equivalent to '~refs/tags/*:refs/tags/*"), and lack > support from porcelain: MY PROPOSAL is to add '--use-separate-tags' > (like old '--use-separate-remote') to "git clone" and "git remote add", > and perhaps '--alternate' as equivalent to '--no-separate-tags' to > "git remote add". That requires you to know about the (potential) tag collision (and remember to use your option) before fetching from the remote repo. Also, even with your added option - which we can use when interfacing unrelated projects from a single repo - the expectation (common case) is still that Git will pollute your local tag namespace with remote tags. Some of us consider this a bug/misfeature in its own right. And we hold that opinion while still agreeing with you that tags "should USUALLY be global". > > - Lack of consistency in which fetch refspecs must be listed in the > > configuration. (i.e. implicit vs. explicit fetch refspecs). My proposal > > tries to address this as well. > > Could you repeat your proposal? http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165885 > Do I remember it correctly that with > 'autofollow' refspec (valid only for tags... well, perhaps also for > notes and replacements) you want to specify defaults in config > explicitely > > [remote "origin"] > url = git://git.example.com/repo.git > fetch = +refs/heads/*:refs/remotes/origin/* > fetch = ~refs/tags/*:refs/tags/* Yes, replicating existing behavior w/explicit refspecs would look like this: [remote "origin"] url = git://git.example.com/repo.git fetch = +HEAD:refs/remotes/origin/HEAD fetch = +refs/heads/*:refs/remotes/origin/* fetch = ~refs/tags/*:refs/tags/* > Perhaps with > > fetch = +refs/heads/*:refs/remotes/origin/heads/* FTR, my new/proposed refspecs would look like this: [remote "origin"] url = git://git.example.com/repo.git fetch = +HEAD:refs/remotes/origin/HEAD fetch = +refs/heads/*:refs/remotes/origin/heads* fetch = ~+refs/tags/*:refs/remotes/origin/tags/* ( fetch = +refs/notes/*:refs/remotes/origin/notes/* ) ( fetch = +refs/replace/*:refs/remotes/origin/replace/* ) > > - Lack of consistency in porcelain interfaces. Some of these have been > > fixed in recent Git version, but some are yet to be fixed: E.g. some > > find the use of FETCH_HEAD confusing (when does fetch update the > > remote refs, and when does it update FETCH_HEAD instead?). > > One of problems is how to keep the fact that > > $ git pull <URL> <branch> > > does one-off pull without creating remote or remote-tracking branch. > But I agree that behavior of > > $ git pull <remote> <branch> > > can be confusing. Yes, to me it seems intuitive that when you specify <URL> (even if <URL> corresponds to an existing remote) you do NOT update remote-tracking refs, but if you use <remote>, you should ALWAYS update remote-tracking refs. Others may disagree. > > Others (myself included) wonder why 'git push' by default updates > > > > remote branches with matching names, while 'git pull' relies on the > > explicitly configured upstreams to update the local refs. (FWIW, > > I've mitigated this last complaint insisting that all users at > > $dayjob run "git config --global push.default tracking" immediately > > after installing Git.) There are other UI inconsistencies too that > > escape me ATM. > > IMHO that's not inconsisnency in Git, this is just reflection of the > fact that in most common case the situation is *assymetric* with > respect to fetch and push; you fetch from other people repositories, > but you push to (usually single, perhaps mirrored) your own publishing > repository. For this situation 'push.default = matching' works > perfectly. It may seem so, but in my experience it doesn't really work perfectly: Even if I fully control the repo I push to, I still want precise control over what I push there. Sometimes I may working on 'next' and 'master' in parallel, and I might have finished and tested some bugfixes on 'master', while I still have unfinished/untested stuff on 'next'. When I 'git push' from 'master', I DO NOT want 'next' to be pushed (unless I have explicitly asked for it). If I'm pushing to a shared repo (a very common workplace setup), this default is even more potentially damaging (especially if I don't discover what's actually happening by scanning the output from 'git push'). This is one area where Git's current default behavior is less conservative than I would like. Have fun! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-13 23:36 ` Johan Herland @ 2011-02-14 7:35 ` Junio C Hamano 2011-02-14 9:18 ` Johan Herland 2011-02-14 9:40 ` [1.8.0] Provide proper remote ref namespaces Jakub Narebski 1 sibling, 1 reply; 104+ messages in thread From: Junio C Hamano @ 2011-02-14 7:35 UTC (permalink / raw) To: Johan Herland Cc: Jakub Narebski, git, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: > Yes, replicating existing behavior w/explicit refspecs would look like this: > > [remote "origin"] > url = git://git.example.com/repo.git > fetch = +HEAD:refs/remotes/origin/HEAD > fetch = +refs/heads/*:refs/remotes/origin/* > fetch = ~refs/tags/*:refs/tags/* While this is fine, I am not sure about the "HEAD" part. Most of the protocol do not convey which branch HEAD points at (instead "clone" has to guess), which eventually needs to be fixed. Incremental updates via "fetch" does not touch "HEAD" at all by design; unlike the real branch heads "remotes/origin/$branch" that are used to keep copies of what are at the remote, "remotes/origin/HEAD" is meant to be used by the local repository to designate which of the remote branch is considered the primary branch from local repository owner's point of view, primarily so that you can say "origin" locally to mean "origin/next" by setting the symref origin/HEAD to point at it. In that sense, the guess made by "clone" is only used to give an initial value. > FTR, my new/proposed refspecs would look like this: > > [remote "origin"] > url = git://git.example.com/repo.git > fetch = +HEAD:refs/remotes/origin/HEAD > fetch = +refs/heads/*:refs/remotes/origin/heads* > fetch = ~+refs/tags/*:refs/remotes/origin/tags/* > ( fetch = +refs/notes/*:refs/remotes/origin/notes/* ) > ( fetch = +refs/replace/*:refs/remotes/origin/replace/* ) I think you meant "refs/remotes/origin/heads/*" (note the slash) on the RHS of the branch refspecs. How's that different from refs/*:refs/remotes/origin/* by the way? Also if you give tags a totally separate namespace, I don't see much reason to still give it the "auto-follow" semantics. It is far simpler to explain if you just fetch all of them and be done with it, no? > Yes, to me it seems intuitive that when you specify <URL> (even if <URL> > corresponds to an existing remote) you do NOT update remote-tracking refs, > but if you use <remote>, you should ALWAYS update remote-tracking refs. > Others may disagree. One argument for disagreement used to be that an explicit fetch of a single branch was a deliberate way to avoid updating the tracking branch before examining what has been changed (i.e. "git fetch origin master" followed by "git log origin/master..FETCH_HEAD" and hopefully followed by "git pull origin" or somesuch). But that was before reflog was adopted as a reliable safety measure, and I don't think people should rely on that behaviour anymore. I would actually make an even stronger point that people should not base their workflow on keeping remote tracking refs deliberately stale, which is exactly the "feature" was meant to be used for. What has happened on the other end has already happened whether you like it or not, and there is no point in your locally pretending that it didn't happen. If you don't like the latest update there, you go talk to the party that control the remote and rectify the situation with them. It may involve pushing a reverting or correcting commit over there, or in the worst case you simply stop pulling from them, forking the project in effect at that point. > It may seem so, but in my experience it doesn't really work perfectly: Even > if I fully control the repo I push to, I still want precise control over > what I push there. Sometimes I may working on 'next' and 'master' in > parallel, and I might have finished and tested some bugfixes on 'master', > while I still have unfinished/untested stuff on 'next'. Yes, I do this all the time and I often say "git push ko maint master" (ko is my name for the k.org repo). I however don't feel inconvenienced by it precisely because when I make such a push, I _know_ that I want to push only these two branches. Saying "only these two branches" explicitly from the command line, and seeing only these two branches go out, are very assuring to me. I usually try to be much more organized to make sure all four integration branches satisfy certain preconditions before pushing, and I say "git push ko" only after I make sure they do. I consider it is a good UI design to force myself to type more when I am doing something un(der)disciplined and to let me type less when I am following a good project hygiene. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-14 7:35 ` Junio C Hamano @ 2011-02-14 9:18 ` Johan Herland 2011-02-14 9:59 ` Jakub Narebski 2011-02-14 18:06 ` Re* " Junio C Hamano 0 siblings, 2 replies; 104+ messages in thread From: Johan Herland @ 2011-02-14 9:18 UTC (permalink / raw) To: Junio C Hamano Cc: Jakub Narebski, git, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Monday 14 February 2011, Junio C Hamano wrote: > Johan Herland <johan@herland.net> writes: > > Yes, replicating existing behavior w/explicit refspecs would look like: > > [remote "origin"] > > > > url = git://git.example.com/repo.git > > fetch = +HEAD:refs/remotes/origin/HEAD > > fetch = +refs/heads/*:refs/remotes/origin/* > > fetch = ~refs/tags/*:refs/tags/* > > While this is fine, I am not sure about the "HEAD" part. Most of the > protocol do not convey which branch HEAD points at (instead "clone" has > to guess), which eventually needs to be fixed. Incremental updates via > "fetch" does not touch "HEAD" at all by design; unlike the real branch > heads "remotes/origin/$branch" that are used to keep copies of what are > at the remote, "remotes/origin/HEAD" is meant to be used by the local > repository to designate which of the remote branch is considered the > primary branch from local repository owner's point of view, primarily so > that you can say "origin" locally to mean "origin/next" by setting the > symref origin/HEAD to point at it. In that sense, the guess made by > "clone" is only used to give an initial value. Ah, ok. I've misunderstood the purpose of "remotes/origin/HEAD" then. Feel free to remove that refspec line from my proposal, and leave it as a special-purpose thing set up by clone (and maintained by the user thereafter). Still (as I think was recently discussed in another thread), the existence of remotes/origin/HEAD _does_ cause problems if the origin remote also has a branch called "refs/heads/HEAD" (which would collide when fetched into the local repo). > > FTR, my new/proposed refspecs would look like this: > > [remote "origin"] > > > > url = git://git.example.com/repo.git > > fetch = +HEAD:refs/remotes/origin/HEAD > > fetch = +refs/heads/*:refs/remotes/origin/heads* > > fetch = ~+refs/tags/*:refs/remotes/origin/tags/* > > > > ( fetch = +refs/notes/*:refs/remotes/origin/notes/* ) > > ( fetch = +refs/replace/*:refs/remotes/origin/replace/* ) > > I think you meant "refs/remotes/origin/heads/*" (note the slash) on the > RHS of the branch refspecs. Indeed. Thanks for pointing out the typo. > How's that different from refs/*:refs/remotes/origin/* by the way? It's not, except that "refs/*:refs/remotes/origin/*" would fetch a too-large superset. E.g. it would fetch "refs/remotes/third-party/heads/foo" into "refs/remotes/origin/remotes/third-party/heads/foo", which we probably don't want. > Also > if you give tags a totally separate namespace, I don't see much reason to > still give it the "auto-follow" semantics. It is far simpler to explain > if you just fetch all of them and be done with it, no? Agreed. Also, to quote Peff in http://thread.gmane.org/gmane.comp.version- control.git/160503/focus=160726 : "Now you could argue that auto-follow is not worth the effort. It is somewhat confusing, and I can't think of a time when it ever actually reduced the set of objects I was fetching (as opposed to just fetching all tags). But maybe others have use cases where it matters." So if nobody disagree, I would have no problem with dropping the leading "~" from the refspec, thus disabling auto-following (tracking all tags explicitly instead). > > Yes, to me it seems intuitive that when you specify <URL> (even if > > <URL> corresponds to an existing remote) you do NOT update > > remote-tracking refs, but if you use <remote>, you should ALWAYS > > update remote-tracking refs. Others may disagree. > > One argument for disagreement used to be that an explicit fetch of a > single branch was a deliberate way to avoid updating the tracking branch > before examining what has been changed (i.e. "git fetch origin master" > followed by "git log origin/master..FETCH_HEAD" and hopefully followed by > "git pull origin" or somesuch). But that was before reflog was adopted > as a reliable safety measure, and I don't think people should rely on > that behaviour anymore. > > I would actually make an even stronger point that people should not base > their workflow on keeping remote tracking refs deliberately stale, which > is exactly the "feature" was meant to be used for. What has happened on > the other end has already happened whether you like it or not, and there > is no point in your locally pretending that it didn't happen. If you > don't like the latest update there, you go talk to the party that control > the remote and rectify the situation with them. It may involve pushing a > reverting or correcting commit over there, or in the worst case you > simply stop pulling from them, forking the project in effect at that > point. Agreed. > > It may seem so, but in my experience it doesn't really work perfectly: > > Even if I fully control the repo I push to, I still want precise > > control over what I push there. Sometimes I may working on 'next' and > > 'master' in parallel, and I might have finished and tested some > > bugfixes on 'master', while I still have unfinished/untested stuff on > > 'next'. > > Yes, I do this all the time and I often say "git push ko maint master" > (ko is my name for the k.org repo). I however don't feel inconvenienced > by it precisely because when I make such a push, I _know_ that I want to > push only these two branches. Saying "only these two branches" > explicitly from the command line, and seeing only these two branches go > out, are very assuring to me. I usually try to be much more organized > to make sure all four integration branches satisfy certain preconditions > before pushing, and I say "git push ko" only after I make sure they do. > > I consider it is a good UI design to force myself to type more when I am > doing something un(der)disciplined and to let me type less when I am > following a good project hygiene. I don't doubt that the current behavior works well for you (otherwise I expect you would have changed it). However, what I've seen at $dayjob is that more inexperienced users will often push right after committing, and at that time they're still very much in the "working-on-one-branch" state of mind (as opposed to the "administering-multiple-branches" state of mind), so when they follow up a "git commit" with a "git push" they're surprised (or worse: oblivious) to the fact that "git push" can push multiple branches. I guess it comes down to whether you fundamentally consider "git push" something that pushes multiple _branches_, or something that pushes multiple _commits_. And for the latter of those groups push.default == "matching" is inherently more "dangerous" than for the former. (Granted, me telling everyone to use push.default == "tracking" probably doesn't help them in discovering "git push"'s ability to update multiple branches.) Have fun! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-14 9:18 ` Johan Herland @ 2011-02-14 9:59 ` Jakub Narebski 2011-02-14 17:30 ` Junio C Hamano 2011-02-14 18:06 ` Re* " Junio C Hamano 1 sibling, 1 reply; 104+ messages in thread From: Jakub Narebski @ 2011-02-14 9:59 UTC (permalink / raw) To: Johan Herland Cc: Junio C Hamano, git, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Mon, 14 Feb 2011, Johan Herland wrote: > On Monday 14 February 2011, Junio C Hamano wrote: >> Johan Herland <johan@herland.net> writes: >>> Yes, replicating existing behavior w/explicit refspecs would look like: >>> [remote "origin"] >>> >>> url = git://git.example.com/repo.git >>> fetch = +HEAD:refs/remotes/origin/HEAD Perhaps setHead = master or something like that? >>> fetch = +refs/heads/*:refs/remotes/origin/* >>> fetch = ~refs/tags/*:refs/tags/* >> >> While this is fine, I am not sure about the "HEAD" part. Most of the >> protocol do not convey which branch HEAD points at (instead "clone" has >> to guess), which eventually needs to be fixed. Right. >> Incremental updates via >> "fetch" does not touch "HEAD" at all by design; unlike the real branch >> heads "remotes/origin/$branch" that are used to keep copies of what are >> at the remote, "remotes/origin/HEAD" is meant to be used by the local >> repository to designate which of the remote branch is considered the >> primary branch from local repository owner's point of view, primarily so >> that you can say "origin" locally to mean "origin/next" by setting the >> symref origin/HEAD to point at it. In that sense, the guess made by >> "clone" is only used to give an initial value. Well, we have "git remote set-branch <remote> -a" to re-do this guessing or checking, and update 'remotes/origin/HEAD'... > > Ah, ok. I've misunderstood the purpose of "remotes/origin/HEAD" then. Feel > free to remove that refspec line from my proposal, and leave it as a > special-purpose thing set up by clone (and maintained by the user > thereafter). See above for my `remote.<remote>.setHead` proposal. > Still (as I think was recently discussed in another thread), the existence > of remotes/origin/HEAD _does_ cause problems if the origin remote also has a > branch called "refs/heads/HEAD" (which would collide when fetched into the > local repo). True, though... can't we consider having branch named 'HEAD' as insane? > >>> FTR, my new/proposed refspecs would look like this: >>> [remote "origin"] >>> >>> url = git://git.example.com/repo.git >>> fetch = +HEAD:refs/remotes/origin/HEAD >>> fetch = +refs/heads/*:refs/remotes/origin/heads* >>> fetch = ~+refs/tags/*:refs/remotes/origin/tags/* >>> >>> ( fetch = +refs/notes/*:refs/remotes/origin/notes/* ) >>> ( fetch = +refs/replace/*:refs/remotes/origin/replace/* ) >> >> I think you meant "refs/remotes/origin/heads/*" (note the slash) on the >> RHS of the branch refspecs. > > Indeed. Thanks for pointing out the typo. > >> How's that different from refs/*:refs/remotes/origin/* by the way? > > It's not, except that "refs/*:refs/remotes/origin/*" would fetch a too-large > superset. E.g. it would fetch "refs/remotes/third-party/heads/foo" into > "refs/remotes/origin/remotes/third-party/heads/foo", which we probably don't > want. Note that it is not given that notes and replaces should be per-remote like remote-tracking branches, and not autofollowed like tags. >> Also >> if you give tags a totally separate namespace, I don't see much reason to >> still give it the "auto-follow" semantics. It is far simpler to explain >> if you just fetch all of them and be done with it, no? > > Agreed. Also, to quote Peff in http://thread.gmane.org/gmane.comp.version- > control.git/160503/focus=160726 : > > "Now you could argue that auto-follow is not worth the effort. It is > somewhat confusing, and I can't think of a time when it ever actually > reduced the set of objects I was fetching (as opposed to just fetching > all tags). But maybe others have use cases where it matters." > > So if nobody disagree, I would have no problem with dropping the leading "~" > from the refspec, thus disabling auto-following (tracking all tags > explicitly instead). Well, to make use of somewhat contrived example: with current auto-follow fetching of tags, when somebody tracks e.g. only 'maint' branch, he/she wouldn't get "*-rcN" tags he/she is not interested in. Worth preserving? [...] > I don't doubt that the current behavior works well for you (otherwise I > expect you would have changed it). However, what I've seen at $dayjob is > that more inexperienced users will often push right after committing, and at > that time they're still very much in the "working-on-one-branch" state of > mind (as opposed to the "administering-multiple-branches" state of mind), so > when they follow up a "git commit" with a "git push" they're surprised (or > worse: oblivious) to the fact that "git push" can push multiple branches. > > I guess it comes down to whether you fundamentally consider "git push" > something that pushes multiple _branches_, or something that pushes multiple > _commits_. And for the latter of those groups push.default == "matching" is > inherently more "dangerous" than for the former. (Granted, me telling > everyone to use push.default == "tracking" probably doesn't help them in > discovering "git push"'s ability to update multiple branches.) Another solution is to tech them "topic branch" workflow, i.e. to do new work on new feature branch, and only when it is ready merge it into one of published branches (i.e. those that have matching branch in remote repository they push to). -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-14 9:59 ` Jakub Narebski @ 2011-02-14 17:30 ` Junio C Hamano 0 siblings, 0 replies; 104+ messages in thread From: Junio C Hamano @ 2011-02-14 17:30 UTC (permalink / raw) To: Jakub Narebski Cc: Johan Herland, git, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Jakub Narebski <jnareb@gmail.com> writes: > On Mon, 14 Feb 2011, Johan Herland wrote: >>>> Yes, replicating existing behavior w/explicit refspecs would look like: >>>> [remote "origin"] >>>> >>>> url = git://git.example.com/repo.git >>>> fetch = +HEAD:refs/remotes/origin/HEAD > > Perhaps > > setHead = master > > or something like that? If I understand what Johan is saying correctly, I don't think that is solving any conceived problems. Currently origin/HEAD once initialized does not repoint and that behaviour more or less has been kept on purpose. What it allows us by explicitly saying HEAD in the refspecs is to move away from the "origin/HEAD is under control of the local repository---it determines what you as the cloner consider the primary branch you are interested in in this particular remote" semantics and instead start saying "just like we copy the values of normal refs from the other side to keep track, we want origin/HEAD to _point at_ the branch they pointed at when we looked at them the last time". While I personally think that is also a valid thing to wish for, it probably is a bit too big a change in the semantics at this point. If you mean by "setHead = master" to "set origin/HEAD symref to point at their master", that does not have to live in the config at all. Once you point the symref, nobody will repoint it to anywhere. >>> ... is meant to be used by the local >>> repository to designate which of the remote branch is considered the >>> primary branch from local repository owner's point of view, primarily so >>> that you can say "origin" locally to mean "origin/next" by setting the >>> symref origin/HEAD to point at it.... > > Well, we have "git remote set-branch <remote> -a" to re-do this guessing > or checking, and update 'remotes/origin/HEAD'... That is exactly what I said, isn't it? >> Still (as I think was recently discussed in another thread), the existence >> of remotes/origin/HEAD _does_ cause problems if the origin remote also has a >> branch called "refs/heads/HEAD" (which would collide when fetched into the >> local repo). > > True, though... can't we consider having branch named 'HEAD' as insane? There was a discussion to forbid ([ANYTHING_0-9A-Z]*_)?HEAD as a branch name to reduce confusion, and I think that is probably a sane thing to do without harming anybody in practice. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re* [1.8.0] Provide proper remote ref namespaces 2011-02-14 9:18 ` Johan Herland 2011-02-14 9:59 ` Jakub Narebski @ 2011-02-14 18:06 ` Junio C Hamano 2011-02-14 18:53 ` Jay Soffian 2011-02-15 15:06 ` Johan Herland 1 sibling, 2 replies; 104+ messages in thread From: Junio C Hamano @ 2011-02-14 18:06 UTC (permalink / raw) To: Johan Herland Cc: Jakub Narebski, git, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: > It's not, except that "refs/*:refs/remotes/origin/*" would fetch a too-large > superset. E.g. it would fetch "refs/remotes/third-party/heads/foo" into > "refs/remotes/origin/remotes/third-party/heads/foo", which we probably don't > want. Ah, very true. We are generally not interested in remote's remotes that possibly include ourselves ;-) > "Now you could argue that auto-follow is not worth the effort. It is > somewhat confusing, and I can't think of a time when it ever actually > reduced the set of objects I was fetching (as opposed to just fetching > all tags). But maybe others have use cases where it matters." > > So if nobody disagree, I would have no problem with dropping the leading "~" > from the refspec, thus disabling auto-following (tracking all tags > explicitly instead). I am not sure what you mean by this. I think we agree that it would be Ok if you cannot add "~" in front to cause automatic following when tracking tags in separate namespaces using "refs/tags/*:refs/remotes/origin/tags/*". But are you saying: (1) There is no other change than that; or (2) Even when not using such a refspec i.e. using the traditional "tags live in a single global namespace", automatic following feature will be disabled; I would be moderately unhappy if the latter. > ... However, what I've seen at $dayjob is > that more inexperienced users will often push right after committing, and at > that time they're still very much in the "working-on-one-branch" state of > mind (as opposed to the "administering-multiple-branches" state of mind),... Then "current" mode is a good setting for them, I would presume. I don't think it is a bad idea to make that the default given sufficient lead time to warn the current users, and if we want to make the switch at 1.8.0, the time to start issuing a warning is now. Perhaps like this. -- >8 -- Subject: [1.8.0 RFC] push: start warning upcoming default change for push.default More inexperienced users will often push right after committing, and at that time they're still very much in the "working-on-one-branch" state of mind. "current" would be a safer default mode of operation for 'git push' for them even when they have their personal publishing repository (also in a shared public repository settings, "matching" is rarely the right default mode). In preparation for flipping the default to the "current" mode from the "matching" mode that is the current default, start warning users when they rely on unconfigured "git push" to default to the "matching" mode. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- builtin/push.c | 13 +++++++++++++ cache.h | 1 + environment.c | 2 +- 3 files changed, 15 insertions(+), 1 deletions(-) diff --git a/builtin/push.c b/builtin/push.c index e655eb7..fe6665e 100644 --- a/builtin/push.c +++ b/builtin/push.c @@ -80,10 +80,23 @@ static void setup_push_tracking(void) add_refspec(refspec.buf); } +static void warn_unspecified_push_default_configuration(void) +{ + static int warn_once; + + if (warn_once++) + return; + warning("You do not have an explicit 'matching' setting for push.default"); + warning("Your workflow will be broken at 1.8.0 unless you do so now"); +} + static void setup_default_push_refspecs(void) { switch (push_default) { default: + case PUSH_DEFAULT_UNSPECIFIED: + warn_unspecified_push_default_configuration(); + /* fallthru */ case PUSH_DEFAULT_MATCHING: add_refspec(":"); break; diff --git a/cache.h b/cache.h index d83d68c..6c47867 100644 --- a/cache.h +++ b/cache.h @@ -606,6 +606,7 @@ enum rebase_setup_type { }; enum push_default_type { + PUSH_DEFAULT_UNSPECIFIED = -1, PUSH_DEFAULT_NOTHING = 0, PUSH_DEFAULT_MATCHING, PUSH_DEFAULT_TRACKING, diff --git a/environment.c b/environment.c index 9564475..577177f 100644 --- a/environment.c +++ b/environment.c @@ -47,7 +47,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN; unsigned whitespace_rule_cfg = WS_DEFAULT_RULE; enum branch_track git_branch_track = BRANCH_TRACK_REMOTE; enum rebase_setup_type autorebase = AUTOREBASE_NEVER; -enum push_default_type push_default = PUSH_DEFAULT_MATCHING; +enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED; #ifndef OBJECT_CREATION_MODE #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS #endif ^ permalink raw reply related [flat|nested] 104+ messages in thread
* Re: Re* [1.8.0] Provide proper remote ref namespaces 2011-02-14 18:06 ` Re* " Junio C Hamano @ 2011-02-14 18:53 ` Jay Soffian 2011-02-14 19:44 ` Sverre Rabbelier 2011-02-15 15:06 ` Johan Herland 1 sibling, 1 reply; 104+ messages in thread From: Jay Soffian @ 2011-02-14 18:53 UTC (permalink / raw) To: Junio C Hamano Cc: Johan Herland, Jakub Narebski, git, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Mon, Feb 14, 2011 at 1:06 PM, Junio C Hamano <gitster@pobox.com> wrote: > + warning("You do not have an explicit 'matching' setting for push.default"); > + warning("Your workflow will be broken at 1.8.0 unless you do so now"); That message seems like it would confuse a new user. This seems less confusing to me w/o becoming a paragraph of text that no one will read: push.default is unset; its implicit value is changing in 1.8.0. To squelch this message, set push.default. See push.default in 'git help config'. And update the git config man page entry for push.default to note that matching is the current default behavior and current will be default behavior starting with 1.8.0 (Aside, it would be nice if "git help config push.default" did what I want. :-) j. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Re* [1.8.0] Provide proper remote ref namespaces 2011-02-14 18:53 ` Jay Soffian @ 2011-02-14 19:44 ` Sverre Rabbelier 2011-02-14 19:50 ` Jay Soffian 2011-02-14 23:05 ` Junio C Hamano 0 siblings, 2 replies; 104+ messages in thread From: Sverre Rabbelier @ 2011-02-14 19:44 UTC (permalink / raw) To: Jay Soffian Cc: Junio C Hamano, Johan Herland, Jakub Narebski, git, Jeff King, Matthieu Moy, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Heya, On Mon, Feb 14, 2011 at 19:53, Jay Soffian <jaysoffian@gmail.com> wrote: > push.default is unset; its implicit value is changing in 1.8.0. To squelch > this message, set push.default. See push.default in 'git help config'. This is worse than what Junio suggested because it does not tell you what to set it to. -- Cheers, Sverre Rabbelier ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Re* [1.8.0] Provide proper remote ref namespaces 2011-02-14 19:44 ` Sverre Rabbelier @ 2011-02-14 19:50 ` Jay Soffian 2011-02-14 21:21 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder 2011-02-14 21:57 ` Re* [1.8.0] Provide proper remote ref namespaces Matthieu Moy 2011-02-14 23:05 ` Junio C Hamano 1 sibling, 2 replies; 104+ messages in thread From: Jay Soffian @ 2011-02-14 19:50 UTC (permalink / raw) To: Sverre Rabbelier Cc: Junio C Hamano, Johan Herland, Jakub Narebski, git, Jeff King, Matthieu Moy, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre On Mon, Feb 14, 2011 at 2:44 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote: > Heya, > > On Mon, Feb 14, 2011 at 19:53, Jay Soffian <jaysoffian@gmail.com> wrote: >> push.default is unset; its implicit value is changing in 1.8.0. To squelch >> this message, set push.default. See push.default in 'git help config'. > > This is worse than what Junio suggested because it does not tell you > what to set it to. Which was intentional on my part. If the message says what to set it to, the beginner will just go 'okay' and set it to that, in which case, what is the point of changing the default? Hence pointing to the man page. Alternately, you could take the wall of text approach, which I was trying to avoid: push.default is unset; its implicit value is changing in 1.8.0 from 'matching' to 'current'. To squelch this message and maintain the current behavior post-1.8.0, use 'git config [--global] push.default matching'. To squelch this message and adopt the 1.8.0 behavior now, use 'git config [--global] push.default current'. See 'git help config' and search for 'push.default' for further information. j. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0 RFC] push: start warning upcoming default change for push.default 2011-02-14 19:50 ` Jay Soffian @ 2011-02-14 21:21 ` Jonathan Nieder 2011-02-14 21:41 ` Jay Soffian 2011-02-14 21:57 ` Re* [1.8.0] Provide proper remote ref namespaces Matthieu Moy 1 sibling, 1 reply; 104+ messages in thread From: Jonathan Nieder @ 2011-02-14 21:21 UTC (permalink / raw) To: Jay Soffian Cc: Sverre Rabbelier, Junio C Hamano, Johan Herland, Jakub Narebski, git, Jeff King, Matthieu Moy, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Jay Soffian wrote: > On Mon, Feb 14, 2011 at 2:44 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote: >> On Mon, Feb 14, 2011 at 19:53, Jay Soffian <jaysoffian@gmail.com> wrote: >>> Junio C Hamano wrote: >>>> + warning("You do not have an explicit 'matching' setting for push.default"); >>>> + warning("Your workflow will be broken at 1.8.0 unless you do so now"); [...] >>> push.default is unset; its implicit value is changing in 1.8.0. To squelch >>> this message, set push.default. See push.default in 'git help config'. >> >> This is worse than what Junio suggested because it does not tell you >> what to set it to. > > Which was intentional on my part. If the message says what to set it > to, the beginner will just go 'okay' and set it to that, in which > case, what is the point of changing the default? Wait, why isn't that a good thing? The beginner only has to learn one set of semantics. My only complaint is that the warning does not explain how to specify "squelch this warning and give me the future semantics instead". So maybe: warning: You do not have an explicit 'matching' setting for push.default. warning: Your workflow will be broken at 1.8.0 unless you do so now. hint: See /usr/share/doc/git/RelNotes/1.7.5.txt for details. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0 RFC] push: start warning upcoming default change for push.default 2011-02-14 21:21 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder @ 2011-02-14 21:41 ` Jay Soffian 2011-02-14 21:55 ` Jonathan Nieder 0 siblings, 1 reply; 104+ messages in thread From: Jay Soffian @ 2011-02-14 21:41 UTC (permalink / raw) To: Jonathan Nieder Cc: Sverre Rabbelier, Junio C Hamano, Johan Herland, Jakub Narebski, git, Jeff King, Matthieu Moy, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre On Mon, Feb 14, 2011 at 4:21 PM, Jonathan Nieder <jrnieder@gmail.com> wrote: >> Which was intentional on my part. If the message says what to set it >> to, the beginner will just go 'okay' and set it to that, in which >> case, what is the point of changing the default? > > Wait, why isn't that a good thing? Because 'current' is the more sensible default behavior. If everyone sets push.default to 'matching' because that's what the message advises, what's the point of changing the implicit default to 'current'? j. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0 RFC] push: start warning upcoming default change for push.default 2011-02-14 21:41 ` Jay Soffian @ 2011-02-14 21:55 ` Jonathan Nieder 0 siblings, 0 replies; 104+ messages in thread From: Jonathan Nieder @ 2011-02-14 21:55 UTC (permalink / raw) To: Jay Soffian Cc: Sverre Rabbelier, Junio C Hamano, Johan Herland, Jakub Narebski, git, Jeff King, Matthieu Moy, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Jay Soffian wrote: > If everyone > sets push.default to 'matching' because that's what the message > advises, what's the point of changing the implicit default to > 'current'? That new installations after v1.8.0 would use the more sensible behavior? ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Re* [1.8.0] Provide proper remote ref namespaces 2011-02-14 19:50 ` Jay Soffian 2011-02-14 21:21 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder @ 2011-02-14 21:57 ` Matthieu Moy 2011-02-14 22:35 ` Jeff King 1 sibling, 1 reply; 104+ messages in thread From: Matthieu Moy @ 2011-02-14 21:57 UTC (permalink / raw) To: Jay Soffian Cc: Sverre Rabbelier, Junio C Hamano, Johan Herland, Jakub Narebski, git, Jeff King, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre First, I'd be really glad if push.default changed to "current", that's what I want 99% of cases, if not more. Jay Soffian <jaysoffian@gmail.com> writes: > Alternately, you could take the wall of text approach, which I was > trying to avoid: > > push.default is unset; its implicit value is changing in 1.8.0 from > 'matching' to 'current'. To squelch this message and maintain the current > behavior post-1.8.0, use 'git config [--global] push.default matching'. To > squelch this message and adopt the 1.8.0 behavior now, use > 'git config [--global] push.default current'. See 'git help config' and > search for 'push.default' for further information. I actually like this, although it's a bit verbose: I think telling the user "something will change" without telling what is very frustrating, so the "from 'matching' to 'current'" part seems really good. I'd remove the [] around the --global, to make the command cut-and-paste ready. Advanced users know whether to remove the --global, and newbies don't want to remove it. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Re* [1.8.0] Provide proper remote ref namespaces 2011-02-14 21:57 ` Re* [1.8.0] Provide proper remote ref namespaces Matthieu Moy @ 2011-02-14 22:35 ` Jeff King 2011-02-14 22:38 ` Sverre Rabbelier ` (2 more replies) 0 siblings, 3 replies; 104+ messages in thread From: Jeff King @ 2011-02-14 22:35 UTC (permalink / raw) To: Matthieu Moy Cc: Jay Soffian, Sverre Rabbelier, Junio C Hamano, Johan Herland, Jakub Narebski, git, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre On Mon, Feb 14, 2011 at 10:57:24PM +0100, Matthieu Moy wrote: > Jay Soffian <jaysoffian@gmail.com> writes: > > > Alternately, you could take the wall of text approach, which I was > > trying to avoid: > > > > push.default is unset; its implicit value is changing in 1.8.0 from > > 'matching' to 'current'. To squelch this message and maintain the current > > behavior post-1.8.0, use 'git config [--global] push.default matching'. To > > squelch this message and adopt the 1.8.0 behavior now, use > > 'git config [--global] push.default current'. See 'git help config' and > > search for 'push.default' for further information. > > I actually like this, although it's a bit verbose: I think telling the > user "something will change" without telling what is very frustrating, > so the "from 'matching' to 'current'" part seems really good. I like this one, too. It lays out what is happening and what the possible choices are. I don't think we should be afraid of a lot of text in a change-of-behavior message like this. It's _supposed_ to be annoying and catch their attention, and there are instructions right there for shutting it up. We have used this strategy before, and I don't remember anyone complaining about "this message is too long". > I'd remove the [] around the --global, to make the command > cut-and-paste ready. Advanced users know whether to remove the > --global, and newbies don't want to remove it. Agreed, and put the commands on their own line for simpler cut-and-paste, like: push.default is unset; its implicit value is changing in 1.8.0 from 'matching' to 'current'. To squelch this message and maintain the current behavior post-1.8.0, run: git config --global push.default matching To squelch this message and adopt the 1.8.0 behavior now, run: git config --global push.default current See 'git help config' and search for 'push.default' for further information. I think the whitespace makes it easier to see there are two choices, and most people have some kind of triple-click-to-copy-whole-line in their terminal. -Peff ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Re* [1.8.0] Provide proper remote ref namespaces 2011-02-14 22:35 ` Jeff King @ 2011-02-14 22:38 ` Sverre Rabbelier 2011-02-14 23:36 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder 2011-02-14 23:45 ` Re* [1.8.0] Provide proper remote ref namespaces Junio C Hamano 2 siblings, 0 replies; 104+ messages in thread From: Sverre Rabbelier @ 2011-02-14 22:38 UTC (permalink / raw) To: Jeff King Cc: Matthieu Moy, Jay Soffian, Junio C Hamano, Johan Herland, Jakub Narebski, git, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Heya, On Mon, Feb 14, 2011 at 23:35, Jeff King <peff@peff.net> wrote: > I think the whitespace makes it easier to see there are two choices, and > most people have some kind of triple-click-to-copy-whole-line in their > terminal. +1 to giving a clear way to choose either the current or the new-default behavior. The only thing I can think of to make it even better now is to inline the description of what those two modes mean ;) -- Cheers, Sverre Rabbelier ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0 RFC] push: start warning upcoming default change for push.default 2011-02-14 22:35 ` Jeff King 2011-02-14 22:38 ` Sverre Rabbelier @ 2011-02-14 23:36 ` Jonathan Nieder 2011-02-14 23:45 ` Re* [1.8.0] Provide proper remote ref namespaces Junio C Hamano 2 siblings, 0 replies; 104+ messages in thread From: Jonathan Nieder @ 2011-02-14 23:36 UTC (permalink / raw) To: Jeff King Cc: Matthieu Moy, Jay Soffian, Sverre Rabbelier, Junio C Hamano, Johan Herland, Jakub Narebski, git, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Jeff King wrote: > Agreed, and put the commands on their own line for simpler > cut-and-paste, like: > > push.default is unset; its implicit value is changing in 1.8.0 from > 'matching' to 'current'. To squelch this message and maintain the > current behavior post-1.8.0, run: > > git config --global push.default matching > > To squelch this message and adopt the 1.8.0 behavior now, run: > > git config --global push.default current > > See 'git help config' and search for 'push.default' for further > information. > > I think the whitespace makes it easier to see there are two choices, and > most people have some kind of triple-click-to-copy-whole-line in their > terminal. Yes. Thank you, and sorry about my previous reply that missed the point. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Re* [1.8.0] Provide proper remote ref namespaces 2011-02-14 22:35 ` Jeff King 2011-02-14 22:38 ` Sverre Rabbelier 2011-02-14 23:36 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder @ 2011-02-14 23:45 ` Junio C Hamano 2 siblings, 0 replies; 104+ messages in thread From: Junio C Hamano @ 2011-02-14 23:45 UTC (permalink / raw) To: Jeff King Cc: Matthieu Moy, Jay Soffian, Sverre Rabbelier, Junio C Hamano, Johan Herland, Jakub Narebski, git, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Jeff King <peff@peff.net> writes: > I like this one, too. It lays out what is happening and what the > possible choices are.... Heh, I see others sorted this out while I was looking the other way ;-) Care to roll an appliable patch? ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Re* [1.8.0] Provide proper remote ref namespaces 2011-02-14 19:44 ` Sverre Rabbelier 2011-02-14 19:50 ` Jay Soffian @ 2011-02-14 23:05 ` Junio C Hamano 1 sibling, 0 replies; 104+ messages in thread From: Junio C Hamano @ 2011-02-14 23:05 UTC (permalink / raw) To: Sverre Rabbelier Cc: Jay Soffian, Johan Herland, Jakub Narebski, git, Jeff King, Matthieu Moy, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Sverre Rabbelier <srabbelier@gmail.com> writes: > On Mon, Feb 14, 2011 at 19:53, Jay Soffian <jaysoffian@gmail.com> wrote: >> push.default is unset; its implicit value is changing in 1.8.0. To squelch >> this message, set push.default. See push.default in 'git help config'. > > This is worse than what Junio suggested because it does not tell you > what to set it to. But the weatherbaloon patch from me was equally bad in another sense. I was only showing where the change should go, and not what the precise wording should be. The message triggers not just for people who _do_ use and want to keep using matching semantics (iow, old timers), for whom the weatherbaloon wording is adequate, but also for people who are new and do not have anything configured, majority of which are _suspected_ to be better off using "current" setting (if we don't suspect that, we won't be talking about possibly switching the default in the future). So I would imagine the actual wording should at least explain that there are two plausible choices, and people who want to get used to the upcoming default earlier would want to set it to "current", while others who want to keep the current default would want to set it to "matching", to avoid surprises. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Re* [1.8.0] Provide proper remote ref namespaces 2011-02-14 18:06 ` Re* " Junio C Hamano 2011-02-14 18:53 ` Jay Soffian @ 2011-02-15 15:06 ` Johan Herland 2011-02-15 18:06 ` Junio C Hamano 1 sibling, 1 reply; 104+ messages in thread From: Johan Herland @ 2011-02-15 15:06 UTC (permalink / raw) To: Junio C Hamano Cc: git, Jakub Narebski, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Monday 14 February 2011, Junio C Hamano wrote: > Johan Herland <johan@herland.net> writes: > > So if nobody disagree, I would have no problem with dropping the > > leading "~" from the refspec, thus disabling auto-following > > (tracking all tags explicitly instead). > > I am not sure what you mean by this. I think we agree that it would > be Ok if you cannot add "~" in front to cause automatic following > when tracking tags in separate namespaces using > "refs/tags/*:refs/remotes/origin/tags/*". > > But are you saying: > > (1) There is no other change than that; or > > (2) Even when not using such a refspec i.e. using the traditional > "tags live in a single global namespace", automatic following feature > will be disabled; > > I would be moderately unhappy if the latter. No, I'm saying the former. For the foreseeable future (i.e. long after v1.8.0 is out) we will still have to understand and support the traditional "tags are implicitly auto-followed" and "tags live in a single global namespace" concepts (aka. (a) below). For new-style remotes I propose that all refspecs be explicit, and that auto-follow is disabled (aka. (b) below). But if you try to specify a new-style remote with all tags in a single global namespace, you will NOT get tag autofollowing (aka. (c) below) (a): The current default config, also supported for the foreseeable future (tag refspec is implicit, auto-following is enabled): [remote "origin"] url = ... fetch = +refs/heads/*:refs/remotes/origin/* (b): The proposed default config, using separate per-remote namespaces for tags (tag refspec is explicit, auto-following is disabled): [remote "origin"] url = ... fetch = +refs/heads/*:refs/remotes/origin/heads/* fetch = +refs/tags/*:refs/remotes/origin/tags/* (c): A customized version of the proposed config, using a single global namespace for tags (tag refspec is explicit, auto-following is disabled): [remote "origin"] url = ... fetch = +refs/heads/*:refs/remotes/origin/(heads/)* fetch = refs/tags/*:refs/tags/* (Note that if we cannot reliably detect the difference between old-style (implicit) and new-style (explicit) remotes, we will likely have to add a boolean flag, e.g. "remote.origin.implicitTagFollowing".) > > ... However, what I've seen at $dayjob is > > that more inexperienced users will often push right after > > committing, and at that time they're still very much in the > > "working-on-one-branch" state of mind (as opposed to the > > "administering-multiple-branches" state of mind),... > > Then "current" mode is a good setting for them, I would presume. Arguably in some workflows, 'tracking' may be a more suitable default (i.e. safer for newbies) than 'current', but in practice this shouldn't matter much (local branch names usually correspond to remote branch names). Also, 'tracking' is more complicated when the branch originates locally, and must be created on the server ("git push -u origin <branch>" vs. "git push"). So I agree that 'current' is the best default. ...Johan Offtopic PS: Given that we're leaning towards using 'tracking' to describe the relationship between remote-tracking branches (refs/remotes/*) and remote branches, and 'upstream' to describe the relationship between a local branch and the remote branch it follows/merges (on 'git pull'), wouldn't push.default == "upstream" be more descriptive than push.default == "tracking" ? -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Re* [1.8.0] Provide proper remote ref namespaces 2011-02-15 15:06 ` Johan Herland @ 2011-02-15 18:06 ` Junio C Hamano 2011-02-16 0:54 ` [PATCH] push.default: Rename 'tracking' to 'upstream' Johan Herland 0 siblings, 1 reply; 104+ messages in thread From: Junio C Hamano @ 2011-02-15 18:06 UTC (permalink / raw) To: Johan Herland Cc: git, Jakub Narebski, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: > On Monday 14 February 2011, Junio C Hamano wrote: > ... > For the foreseeable future (i.e. long after v1.8.0 is out) we will still > have to understand and support the traditional "tags are implicitly > auto-followed" and "tags live in a single global namespace" concepts > (aka. (a) below). For new-style remotes I propose that all refspecs be > explicit, and that auto-follow is disabled (aka. (b) below). > > But if you try to specify a new-style remote with all tags in a single > global namespace, you will NOT get tag autofollowing (aka. (c) below) Ok. > (Note that if we cannot reliably detect the difference between old-style > (implicit) and new-style (explicit) remotes, we will likely have to add > a boolean flag, e.g. "remote.origin.implicitTagFollowing".) Ok. >> > ... However, what I've seen at $dayjob is >> > that more inexperienced users will often push right after >> > committing, and at that time they're still very much in the >> > "working-on-one-branch" state of mind (as opposed to the >> > "administering-multiple-branches" state of mind),... >> >> Then "current" mode is a good setting for them, I would presume. > > Arguably in some workflows, 'tracking' may be a more suitable default > (i.e. safer for newbies) than 'current', but in practice this shouldn't > matter much (local branch names usually correspond to remote branch > names). Of course you are right. The "this pulls from there, and pushes back to the same place" model was what I had in mind when I wrote the patch; I just was confused between the "tracking" vs "current" labels. > Offtopic PS: Given that we're leaning towards using 'tracking' to > describe the relationship between remote-tracking branches > (refs/remotes/*) and remote branches, and 'upstream' to describe the > relationship between a local branch and the remote branch it > follows/merges (on 'git pull'), wouldn't > > push.default == "upstream" > > be more descriptive than > > push.default == "tracking" "Local Branch" and "Remote Tracking Branch", both of which physically reside on the local end of the communication and are tied by their "merge/rebase" relationship, are much more distinct than "Remote Branch" and "Remote Tracking Branch" that are tied by their "fetch" relationship. A remote tracking branch is a mere (time-lagged) mirror of the remote branch it tracks, and mental distance between them is much smaller than that of between a local branch and its @{upstream} that is a remote tracking branch. Conceptually the _true_ upstream of a local branch is the remote branch from which its @{upstream} remote tracking branch copies from. So in that sense, I agree "pushing my change to the upstream" would match the mental model of an end user somewhat better than "pushing my change back to what I track". Perhaps leave "tracking" as a deprecated synonym and add "upstream" as the official name of the mode? ^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-15 18:06 ` Junio C Hamano @ 2011-02-16 0:54 ` Johan Herland 2011-02-16 6:35 ` Junio C Hamano 2011-02-16 8:55 ` Matthieu Moy 0 siblings, 2 replies; 104+ messages in thread From: Johan Herland @ 2011-02-16 0:54 UTC (permalink / raw) To: Junio C Hamano Cc: git, Jakub Narebski, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Users are sometimes confused with two different types of "tracking" behavior in Git: "remote-tracking" branches (e.g. refs/remotes/*/*) versus the merge/rebase relationship between a local branch and its @{upstream} (controlled by branch.foo.remote and branch.foo.merge config settings). When the push.default is set to 'tracking', it specifies that a branch should be pushed to its @{upstream} branch. In other words, setting push.default to 'tracking' applies only to the latter of the above two types of "tracking" behavior. In order to make this more understandable to the user, we rename the push.default == 'tracking' option to push.default == 'upstream'. push.default == 'tracking' is left as a deprecated synonym for 'upstream'. Signed-off-by: Johan Herland <johan@herland.net> --- On Tuesday 15 February 2011, Junio C Hamano wrote: > Perhaps leave "tracking" as a deprecated synonym and add "upstream" as > the official name of the mode? This patch does just that. I took the liberty of renaming the setup_push_tracking() function as well, and rephrasing its error messages. Although this may be considered code churn, I think it's worth keeping the function naming closer to the phrasing in the documentation. Have fun! :) ...Johan Documentation/config.txt | 3 ++- builtin/push.c | 10 +++++----- cache.h | 2 +- config.c | 6 ++++-- 4 files changed, 12 insertions(+), 9 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index c5e1835..c995a1a 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1591,7 +1591,8 @@ push.default:: * `matching` - push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default. -* `tracking` - push the current branch to its upstream branch. +* `upstream` - push the current branch to its upstream branch. +* `tracking` - deprecated synonym for `upstream`. * `current` - push the current branch to a branch of the same name. rebase.stat:: diff --git a/builtin/push.c b/builtin/push.c index e655eb7..31da418 100644 --- a/builtin/push.c +++ b/builtin/push.c @@ -64,17 +64,17 @@ static void set_refspecs(const char **refs, int nr) } } -static void setup_push_tracking(void) +static void setup_push_upstream(void) { struct strbuf refspec = STRBUF_INIT; struct branch *branch = branch_get(NULL); if (!branch) die("You are not currently on a branch."); if (!branch->merge_nr || !branch->merge) - die("The current branch %s is not tracking anything.", + die("The current branch %s has no upstream branch.", branch->name); if (branch->merge_nr != 1) - die("The current branch %s is tracking multiple branches, " + die("The current branch %s has multiple upstream branches, " "refusing to push.", branch->name); strbuf_addf(&refspec, "%s:%s", branch->name, branch->merge[0]->src); add_refspec(refspec.buf); @@ -88,8 +88,8 @@ static void setup_default_push_refspecs(void) add_refspec(":"); break; - case PUSH_DEFAULT_TRACKING: - setup_push_tracking(); + case PUSH_DEFAULT_UPSTREAM: + setup_push_upstream(); break; case PUSH_DEFAULT_CURRENT: diff --git a/cache.h b/cache.h index d83d68c..7acf120 100644 --- a/cache.h +++ b/cache.h @@ -608,7 +608,7 @@ enum rebase_setup_type { enum push_default_type { PUSH_DEFAULT_NOTHING = 0, PUSH_DEFAULT_MATCHING, - PUSH_DEFAULT_TRACKING, + PUSH_DEFAULT_UPSTREAM, PUSH_DEFAULT_CURRENT }; diff --git a/config.c b/config.c index 625e051..9184900 100644 --- a/config.c +++ b/config.c @@ -737,8 +737,10 @@ static int git_default_push_config(const char *var, const char *value) push_default = PUSH_DEFAULT_NOTHING; else if (!strcmp(value, "matching")) push_default = PUSH_DEFAULT_MATCHING; - else if (!strcmp(value, "tracking")) - push_default = PUSH_DEFAULT_TRACKING; + else if (!strcmp(value, "upstream")) + push_default = PUSH_DEFAULT_UPSTREAM; + else if (!strcmp(value, "tracking")) /* deprecated */ + push_default = PUSH_DEFAULT_UPSTREAM; else if (!strcmp(value, "current")) push_default = PUSH_DEFAULT_CURRENT; else { -- 1.7.4 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 0:54 ` [PATCH] push.default: Rename 'tracking' to 'upstream' Johan Herland @ 2011-02-16 6:35 ` Junio C Hamano 2011-02-16 8:55 ` Matthieu Moy 1 sibling, 0 replies; 104+ messages in thread From: Junio C Hamano @ 2011-02-16 6:35 UTC (permalink / raw) To: Johan Herland Cc: git, Jakub Narebski, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: > I took the liberty of renaming the setup_push_tracking() function as > well, and rephrasing its error messages. Although this may be > considered code churn, I think it's worth keeping the function naming > closer to the phrasing in the documentation. I don't have any problem with that kind of internal naming clean-up, especially when there is no other change in flight that would interfere or cause conflict with it. Will hold for a few days to see if we see any reasonable objection, and then queue if not. Thanks. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 0:54 ` [PATCH] push.default: Rename 'tracking' to 'upstream' Johan Herland 2011-02-16 6:35 ` Junio C Hamano @ 2011-02-16 8:55 ` Matthieu Moy 2011-02-16 9:42 ` Martin von Zweigbergk 1 sibling, 1 reply; 104+ messages in thread From: Matthieu Moy @ 2011-02-16 8:55 UTC (permalink / raw) To: Johan Herland Cc: Junio C Hamano, git, Jakub Narebski, Jeff King, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: > In order to make this more understandable to the user, we rename the > push.default == 'tracking' option to push.default == 'upstream'. While we're there, shouldn't we also rename 'branch.<remote>.merge' to 'branch.<remote>.upstream'? It has a bit more consequences, since external porcelains/scripts are likely to call "git config branch.foo.merge", and would be broken by such change. But maybe 1.8.0 is the time for this kind of things. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 8:55 ` Matthieu Moy @ 2011-02-16 9:42 ` Martin von Zweigbergk 2011-02-16 10:08 ` Jakub Narebski 2011-02-16 10:54 ` Bernhard R. Link 0 siblings, 2 replies; 104+ messages in thread From: Martin von Zweigbergk @ 2011-02-16 9:42 UTC (permalink / raw) To: Matthieu Moy Cc: Johan Herland, Junio C Hamano, git, Jakub Narebski, Jeff King, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Wed, 16 Feb 2011, Matthieu Moy wrote: > Johan Herland <johan@herland.net> writes: > > > In order to make this more understandable to the user, we rename the > > push.default == 'tracking' option to push.default == 'upstream'. > > While we're there, shouldn't we also rename 'branch.<remote>.merge' to > 'branch.<remote>.upstream'? I have a draft proposal not exactly to rename it, but to replace it by a new branch.<name>.upstream which would point to local ref rather than a ref on the remote, so one would have e.g. branch.topic.upstream = refs/remotes/origin/master. Maybe I should clean up that proposal and send it soon. The topic comes up quite frequently. My biggest concern with it is that it breaks the use case where the remote is not named, i.e. where one has a configuration that looks like: [branch "topic"] remote = git://git.kernel.org/pub/scm/git/git.git merge = master I don't know how common that case is, so I don't know if it would it be acceptable to break it. I would of course not suggest no longer fall back to reading branch.<name>.(remote+merge), but at some point we would drop support for that and then we would disallow that use case. I'm also not sure the benefits are that great; this is just one of those things I think "we should do differently if designing git from scratch". What do you think? Should I even bother sending a formal proposal? /Martin ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 9:42 ` Martin von Zweigbergk @ 2011-02-16 10:08 ` Jakub Narebski 2011-02-16 10:26 ` Matthieu Moy 2011-02-16 10:54 ` Bernhard R. Link 1 sibling, 1 reply; 104+ messages in thread From: Jakub Narebski @ 2011-02-16 10:08 UTC (permalink / raw) To: Martin von Zweigbergk Cc: Matthieu Moy, Johan Herland, Junio C Hamano, git, Jeff King, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Dnia środa 16. lutego 2011 10:42, Martin von Zweigbergk napisał: > On Wed, 16 Feb 2011, Matthieu Moy wrote: > > > Johan Herland <johan@herland.net> writes: > > > > > In order to make this more understandable to the user, we rename the > > > push.default == 'tracking' option to push.default == 'upstream'. > > > > While we're there, shouldn't we also rename 'branch.<remote>.merge' to > > 'branch.<remote>.upstream'? > > I have a draft proposal not exactly to rename it, but to replace it by > a new branch.<name>.upstream which would point to local ref rather > than a ref on the remote, so one would have e.g. > branch.topic.upstream = refs/remotes/origin/master. Maybe I should > clean up that proposal and send it soon. The topic comes up quite > frequently. Actually while I think that it makes more sense to use local ref for 'branch.<name>.merge' because it is what is merged, i.e.: branch.topic.merge = refs/remotes/origin/master or in case of tracking local branch branch.topic.remote = . branch.topic.merge = refs/heads/master I think that for 'branch.<name>.upstream' it would make more sense to use the name that *upstream* uses, i.e. branch.topic.upstream = refs/heads/master -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 10:08 ` Jakub Narebski @ 2011-02-16 10:26 ` Matthieu Moy 2011-02-16 10:27 ` Sverre Rabbelier 0 siblings, 1 reply; 104+ messages in thread From: Matthieu Moy @ 2011-02-16 10:26 UTC (permalink / raw) To: Jakub Narebski Cc: Martin von Zweigbergk, Johan Herland, Junio C Hamano, git, Jeff King, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Jakub Narebski <jnareb@gmail.com> writes: > Actually while I think that it makes more sense to use local ref for > 'branch.<name>.merge' because it is what is merged, i.e.: > > branch.topic.merge = refs/remotes/origin/master [...] > I think that for 'branch.<name>.upstream' it would make more sense to > use the name that *upstream* uses, i.e. > > branch.topic.upstream = refs/heads/master I disagree. Both --set-upstream and @{upstream} both refer to refs/remotes/origin/master, i.e. the remote-tracking name in the local repository, not to the local name in the remote repository. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 10:26 ` Matthieu Moy @ 2011-02-16 10:27 ` Sverre Rabbelier 2011-02-16 17:56 ` Junio C Hamano 0 siblings, 1 reply; 104+ messages in thread From: Sverre Rabbelier @ 2011-02-16 10:27 UTC (permalink / raw) To: Matthieu Moy Cc: Jakub Narebski, Martin von Zweigbergk, Johan Herland, Junio C Hamano, git, Jeff King, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Heya, On Wed, Feb 16, 2011 at 10:26, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: >> I think that for 'branch.<name>.upstream' it would make more sense to I like the idea of naming it 'upstream', although I don't care much either way for restricting what you specify. I've always thought 'merge' was a curious name that didn't really fit with my mental model of what I was configuring. -- Cheers, Sverre Rabbelier ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 10:27 ` Sverre Rabbelier @ 2011-02-16 17:56 ` Junio C Hamano 2011-02-16 18:08 ` Sverre Rabbelier ` (2 more replies) 0 siblings, 3 replies; 104+ messages in thread From: Junio C Hamano @ 2011-02-16 17:56 UTC (permalink / raw) To: Sverre Rabbelier Cc: Matthieu Moy, Jakub Narebski, Martin von Zweigbergk, Johan Herland, git, Jeff King, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Sverre Rabbelier <srabbelier@gmail.com> writes: > On Wed, Feb 16, 2011 at 10:26, Matthieu Moy > <Matthieu.Moy@grenoble-inp.fr> wrote: >>> I think that for 'branch.<name>.upstream' it would make more sense to > > I like the idea of naming it 'upstream', although I don't care much > either way for restricting what you specify. I've always thought > 'merge' was a curious name that didn't really fit with my mental model > of what I was configuring. That pretty much comes from the days back when 'merge' was the only method of integrating with what the other party did. I agree "upstream" is a better name. The name "merge" is about what operation uses it, and does not say why it is used (i.e. "we merge with it because it is _the other end_ of the integration"); the latter is a more important thing to express. Until another method of integration (namely, rebase) started using the same mechanism, this was Ok, but when it happend, the name "merge" immediately stopped making sense, but we did not rename nor give a synonym to the variable. The name "upstream" prepares us for yet another method of integration that nobody has invented yet. As to its value being what the other end calls the source, I think it is not a good idea to change it, and it is even a worse idea to add a new configuration variable that points into the tracking branches on our side. @{upstream} is a short-hand notation to call the tracking branch of the "upstream" we have been discussing, and has to point at refs/remotes/ hierarchy, but the entire point of the notation is that the users do not have to see/type "refs/remotes/" when they say $ git merge @{upstream} but at the level of an end-user's world-view, his branch that was forked from origin's "master" integrates with origin's "master", and the use of an intermediary, the refs/remotes/origin/master remote tracking branch that is kept on the local side, is a mere implementation detail. IOW, I consider --set-upstream that takes refs/remotes without bothering to go through the remotes.<name>.fetch mapping is a design bug (it may have come from sloppy initial coding---it certainly is easier to store what you get without computing anything). That may be something we might want to fix in 1.8.0. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 17:56 ` Junio C Hamano @ 2011-02-16 18:08 ` Sverre Rabbelier 2011-02-16 18:37 ` Junio C Hamano 2011-02-18 0:51 ` Martin von Zweigbergk 2 siblings, 0 replies; 104+ messages in thread From: Sverre Rabbelier @ 2011-02-16 18:08 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jakub Narebski, Martin von Zweigbergk, Johan Herland, git, Jeff King, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Heya, On Wed, Feb 16, 2011 at 17:56, Junio C Hamano <gitster@pobox.com> wrote: > That pretty much comes from the days back when 'merge' was the only method > of integrating with what the other party did. <snip> Cool, thanks for the history. -- Cheers, Sverre Rabbelier ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 17:56 ` Junio C Hamano 2011-02-16 18:08 ` Sverre Rabbelier @ 2011-02-16 18:37 ` Junio C Hamano 2011-02-18 0:51 ` Martin von Zweigbergk 2 siblings, 0 replies; 104+ messages in thread From: Junio C Hamano @ 2011-02-16 18:37 UTC (permalink / raw) To: Junio C Hamano Cc: Sverre Rabbelier, Matthieu Moy, Jakub Narebski, Martin von Zweigbergk, Johan Herland, git, Jeff King, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre Junio C Hamano <gitster@pobox.com> writes: > IOW, I consider --set-upstream that takes refs/remotes without bothering > to go through the remotes.<name>.fetch mapping is a design bug (it may > have come from sloppy initial coding---it certainly is easier to store > what you get without computing anything). That may be something we might > want to fix in 1.8.0. Please scratch this paragraph; this was a sloppy thinking on my part. The option, and its cousin --track, do call into setup_tracking() to look up the mapping. The --set-upstream option needs to set both which remote's what branch, and refs/remotes/origin/master is a way to say "origin's master" and it was inevitable to expose refs/remotes/ to the UI level if you wanted to implement it as an option with a single argument. So in that sense there is nothing to fix. Conceptually, "git branch --set-upstream=master --set-remote=origin" is what it really wants to say, even though that is probably longer to type. There still might be a room for UI improvement. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 17:56 ` Junio C Hamano 2011-02-16 18:08 ` Sverre Rabbelier 2011-02-16 18:37 ` Junio C Hamano @ 2011-02-18 0:51 ` Martin von Zweigbergk 2011-02-18 0:57 ` Martin von Zweigbergk 2 siblings, 1 reply; 104+ messages in thread From: Martin von Zweigbergk @ 2011-02-18 0:51 UTC (permalink / raw) To: Junio C Hamano Cc: Sverre Rabbelier, Matthieu Moy, Jakub Narebski, Martin von Zweigbergk, Johan Herland, git, Jeff King, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre On Wed, 16 Feb 2011, Junio C Hamano wrote: > As to its value being what the other end calls the source, I think it is > not a good idea to change it, and it is even a worse idea to add a new > configuration variable that points into the tracking branches on our side. > @{upstream} is a short-hand notation to call the tracking branch of the > "upstream" we have been discussing, and has to point at refs/remotes/ > hierarchy, but the entire point of the notation is that the users do not > have to see/type "refs/remotes/" when they say > > $ git merge @{upstream} > > but at the level of an end-user's world-view, his branch that was forked > from origin's "master" integrates with origin's "master", and the use of > an intermediary, the refs/remotes/origin/master remote tracking branch > that is kept on the local side, is a mere implementation detail. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-18 0:51 ` Martin von Zweigbergk @ 2011-02-18 0:57 ` Martin von Zweigbergk 0 siblings, 0 replies; 104+ messages in thread From: Martin von Zweigbergk @ 2011-02-18 0:57 UTC (permalink / raw) To: Martin von Zweigbergk Cc: Junio C Hamano, Sverre Rabbelier, Matthieu Moy, Jakub Narebski, Johan Herland, git, Jeff King, Dmitry Potapov, Nguyen Thai Ngoc Duy, Nicolas Pitre On Thu, 17 Feb 2011, Martin von Zweigbergk wrote: Sorry, sent by mistake (wrong key). > On Wed, 16 Feb 2011, Junio C Hamano wrote: > > > As to its value being what the other end calls the source, I think it is > > not a good idea to change it, and it is even a worse idea to add a new > > configuration variable that points into the tracking branches on our side. > > @{upstream} is a short-hand notation to call the tracking branch of the > > "upstream" we have been discussing, and has to point at refs/remotes/ > > hierarchy, but the entire point of the notation is that the users do not > > have to see/type "refs/remotes/" when they say > > > > $ git merge @{upstream} What I meant to say was that I'm not sure I agree that the point of the @{upstream} notation is to hide the refs/remotes hierarchy. At least to me. I think more important is having a single way to refer to the upstream, whatever its value may be. > > > > but at the level of an end-user's world-view, his branch that was forked > > from origin's "master" integrates with origin's "master", and the use of > > an intermediary, the refs/remotes/origin/master remote tracking branch > > that is kept on the local side, is a mere implementation detail. Anyway, I agree with with this part. And I'm happy Johan adding the "upstream" alias. /Martin ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH] push.default: Rename 'tracking' to 'upstream' 2011-02-16 9:42 ` Martin von Zweigbergk 2011-02-16 10:08 ` Jakub Narebski @ 2011-02-16 10:54 ` Bernhard R. Link 1 sibling, 0 replies; 104+ messages in thread From: Bernhard R. Link @ 2011-02-16 10:54 UTC (permalink / raw) To: Martin von Zweigbergk Cc: Matthieu Moy, Johan Herland, Junio C Hamano, git, Jakub Narebski, Jeff King, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre * Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> [110216 10:43]: > On Wed, 16 Feb 2011, Matthieu Moy wrote: > > > Johan Herland <johan@herland.net> writes: > > > > > In order to make this more understandable to the user, we rename the > > > push.default == 'tracking' option to push.default == 'upstream'. > > > > While we're there, shouldn't we also rename 'branch.<remote>.merge' to > > 'branch.<remote>.upstream'? > > I have a draft proposal not exactly to rename it, but to replace it by > a new branch.<name>.upstream which would point to local ref rather > than a ref on the remote, so one would have e.g. > branch.topic.upstream = refs/remotes/origin/master. Making it name a local ref name would also make it easier to add support for listing multiple references. The use case I miss support for (please hint me if this is already possible somehow), is having multiple remotes where other people (or more importantly I at other computers for projects without central repository) add commits. Currently one needs to fetch all the remotes and then manually do a merge remote1/branchname remote2/branchname remote3/branchname and so on. It would be nice if a single git pull could do that. Bernhard R. Link ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-13 23:36 ` Johan Herland 2011-02-14 7:35 ` Junio C Hamano @ 2011-02-14 9:40 ` Jakub Narebski 2011-02-14 15:45 ` Marc Branchaud 2011-02-14 18:30 ` Junio C Hamano 1 sibling, 2 replies; 104+ messages in thread From: Jakub Narebski @ 2011-02-14 9:40 UTC (permalink / raw) To: Johan Herland Cc: git, Jeff King, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On Mon, 14 Feb 2011, Johan Herland wrote: > On Friday 11 February 2011, Jakub Narebski wrote: > > Johan Herland <johan@herland.net> writes: > > > - Lack of consistency in the ref namespace (refs/remotes/$remote/* vs. > > > refs/tags/*). Also not clear from the current layout where to add new > > > types of refs (e.g. notes, replace). My proposal tries to address this > > > issue. > > > > The lack of consistency is there because tags should USUALLY be global > > (there should be only one v1.7.4), while branch names should be local > > (my 'master' branch is not your 'master' branch). > > > > In some cases, like joining or subtree-merging unrelated projects we > > would want local / per-remote tags: 'v1.7.4' in main project is not > > 'v1.7.4' in 'foo' subproject (in 'foo' remote). Currently we lack a > > way to specify that (the 'autofollow' refspec proposal, default > > behaviour would be equivalent to '~refs/tags/*:refs/tags/*"), and lack > > support from porcelain: MY PROPOSAL is to add '--use-separate-tags' > > (like old '--use-separate-remote') to "git clone" and "git remote add", > > and perhaps '--alternate' as equivalent to '--no-separate-tags' to > > "git remote add". > > That requires you to know about the (potential) tag collision (and remember > to use your option) before fetching from the remote repo. No, what you need to know at te point of adding remote with "git remote add" is to know whether the repository is alternative / extra repository of the same project (common tags), or whether it is separate project (separate tags). Which you should know at this point. > Also, even with your added option - which we can use when interfacing > unrelated projects from a single repo - the expectation (common case) is > still that Git will pollute your local tag namespace with remote tags. Some > of us consider this a bug/misfeature in its own right. And we hold that > opinion while still agreeing with you that tags "should USUALLY be global". I don't think the distinction is between local and per-remote tags. It is about local (your own) bookmarking tags versus global repository tags (_not_ per-remote) for marking releases. I guess that current layout might be not best, but per-remote tags isn't it either, in my opinion. Please consider this use case: Let's assume that current maintainer steps aside for a bit, and new interim temporary maintainer takes mantle. One would add new remote _temporarily_, but one would want for tags that temporary maintainer created to be as good as tags from 'origin' remote... and not be deleted when you remove temp remote and its remote-tracking branches. [...] > > Do I remember it correctly that with > > 'autofollow' refspec (valid only for tags... well, perhaps also for > > notes and replacements) you want to specify defaults in config > > explicitely > > > > [remote "origin"] > > url = git://git.example.com/repo.git > > fetch = +refs/heads/*:refs/remotes/origin/* > > fetch = ~refs/tags/*:refs/tags/* > > Yes, replicating existing behavior w/explicit refspecs would look like this: > > [remote "origin"] > url = git://git.example.com/repo.git > fetch = +HEAD:refs/remotes/origin/HEAD > fetch = +refs/heads/*:refs/remotes/origin/* > fetch = ~refs/tags/*:refs/tags/* I'm not sure about HEAD refspec; we don't have one for transferring symrefs. "git push <remote> HEAD" doesn't push HEAD ut the current branch. [...] > > > - Lack of consistency in porcelain interfaces. Some of these have been > > > fixed in recent Git version, but some are yet to be fixed: E.g. some > > > find the use of FETCH_HEAD confusing (when does fetch update the > > > remote refs, and when does it update FETCH_HEAD instead?). > > > > One of problems is how to keep the fact that > > > > $ git pull <URL> <branch> > > > > does one-off pull without creating remote or remote-tracking branch. > > But I agree that behavior of > > > > $ git pull <remote> <branch> > > > > can be confusing. > > Yes, to me it seems intuitive that when you specify <URL> (even if <URL> > corresponds to an existing remote) you do NOT update remote-tracking refs, > but if you use <remote>, you should ALWAYS update remote-tracking refs. > Others may disagree. I agree. Keeping remote-tracking branches stale on purpose doesn't look for me like a sane workflow. > > > Others (myself included) wonder why 'git push' by default updates > > > > > > remote branches with matching names, while 'git pull' relies on the > > > explicitly configured upstreams to update the local refs. (FWIW, > > > I've mitigated this last complaint insisting that all users at > > > $dayjob run "git config --global push.default tracking" immediately > > > after installing Git.) There are other UI inconsistencies too that > > > escape me ATM. > > > > IMHO that's not inconsistency in Git, this is just reflection of the > > fact that in most common case the situation is *assymetric* with > > respect to fetch and push; you fetch from other people repositories, > > but you push to (usually single, perhaps mirrored) your own publishing > > repository. For this situation 'push.default = matching' works > > perfectly. > > It may seem so, but in my experience it doesn't really work perfectly: Even > if I fully control the repo I push to, I still want precise control over > what I push there. Sometimes I may working on 'next' and 'master' in > parallel, and I might have finished and tested some bugfixes on 'master', > while I still have unfinished/untested stuff on 'next'. When I 'git push' > from 'master', I DO NOT want 'next' to be pushed (unless I have explicitly > asked for it). Then do "git push <remote> HEAD" to push current branch only in this *special case* (I think there was proposal to have "git push HEAD" to push to default remote, but I don't know if it was accepted; well, this idea can be resurrected if it isn't in). > If I'm pushing to a shared repo (a very common workplace setup), this > default is even more potentially damaging (especially if I don't discover > what's actually happening by scanning the output from 'git push'). > > This is one area where Git's current default behavior is less conservative > than I would like. I think that it would be good idea to have "git push --ask", which when on terminal would present you with the list of branches that would be pushed, and ask for confirmation if you push more than one branch or something (or perhaps even "git push --interactive"). But this requires some discipline to *not* do work in progress on published branches (matching). -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-14 9:40 ` [1.8.0] Provide proper remote ref namespaces Jakub Narebski @ 2011-02-14 15:45 ` Marc Branchaud 2011-02-14 19:35 ` Nicolas Pitre 2011-02-14 18:30 ` Junio C Hamano 1 sibling, 1 reply; 104+ messages in thread From: Marc Branchaud @ 2011-02-14 15:45 UTC (permalink / raw) To: Jakub Narebski Cc: Johan Herland, git, Jeff King, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre On 11-02-14 04:40 AM, Jakub Narebski wrote: > On Mon, 14 Feb 2011, Johan Herland wrote: >> On Friday 11 February 2011, Jakub Narebski wrote: >>> Johan Herland <johan@herland.net> writes: > >>>> - Lack of consistency in the ref namespace (refs/remotes/$remote/* vs. >>>> refs/tags/*). Also not clear from the current layout where to add new >>>> types of refs (e.g. notes, replace). My proposal tries to address this >>>> issue. >>> >>> The lack of consistency is there because tags should USUALLY be global >>> (there should be only one v1.7.4), while branch names should be local >>> (my 'master' branch is not your 'master' branch). >>> >>> In some cases, like joining or subtree-merging unrelated projects we >>> would want local / per-remote tags: 'v1.7.4' in main project is not >>> 'v1.7.4' in 'foo' subproject (in 'foo' remote). Currently we lack a >>> way to specify that (the 'autofollow' refspec proposal, default >>> behaviour would be equivalent to '~refs/tags/*:refs/tags/*"), and lack >>> support from porcelain: MY PROPOSAL is to add '--use-separate-tags' >>> (like old '--use-separate-remote') to "git clone" and "git remote add", >>> and perhaps '--alternate' as equivalent to '--no-separate-tags' to >>> "git remote add". >> >> That requires you to know about the (potential) tag collision (and remember >> to use your option) before fetching from the remote repo. > > No, what you need to know at te point of adding remote with "git remote add" > is to know whether the repository is alternative / extra repository of the > same project (common tags), or whether it is separate project (separate > tags). > > Which you should know at this point. > >> Also, even with your added option - which we can use when interfacing >> unrelated projects from a single repo - the expectation (common case) is >> still that Git will pollute your local tag namespace with remote tags. Some >> of us consider this a bug/misfeature in its own right. And we hold that >> opinion while still agreeing with you that tags "should USUALLY be global". > > I don't think the distinction is between local and per-remote tags. It > is about local (your own) bookmarking tags versus global repository tags > (_not_ per-remote) for marking releases. > > I guess that current layout might be not best, but per-remote tags isn't it > either, in my opinion. > > > Please consider this use case: > > Let's assume that current maintainer steps aside for a bit, and new interim > temporary maintainer takes mantle. One would add new remote _temporarily_, > but one would want for tags that temporary maintainer created to be as good > as tags from 'origin' remote... and not be deleted when you remove temp > remote and its remote-tracking branches. I take it that "origin" here refers to the first maintainer's repository. I suggest that the correct thing to do in this case is to change the URL of the "origin" remote. Because really that's what you want: the temp maintainer's repo is the equivalent of the first maintainer's repo. When the first maintainer returns he'll update his own repo to match the temp maintainer's, then everyone can switch their remotes back to the original repo. (Perhaps git-remote could even learn an "import-tags" subcommand to help the original maintainer here.) For me, having more than one remote be *simultaneously* authoritative for a set of tags is the unusual case. I find that most projects, no matter how decentralized, need to agree upon the project's "official" history, and that such agreement is almost always encapsulated within a single, "official" repository. To have more than one is, frankly, insane. So to me it seems completely natural to think of a project's "official" tags as the ones that are obtained from the project's "official" repository. It follows that tags should subscribe to the same remote-ref model as branches. The benefits are powerful: consistency; deals naturally with imported histories from different repositories; and allows automatic propagation of updated (i.e. moved) tags from remotes to clones (yes tags *should* never move, but they do, often for good reason and occasionally as part of a project's natural evolution). There have been several comments disparaging per-remote tags, but people are clearly dissatisfied with the status quo. Can anyone propose another alternative? M. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-14 15:45 ` Marc Branchaud @ 2011-02-14 19:35 ` Nicolas Pitre 0 siblings, 0 replies; 104+ messages in thread From: Nicolas Pitre @ 2011-02-14 19:35 UTC (permalink / raw) To: Marc Branchaud Cc: Jakub Narebski, Johan Herland, git, Jeff King, Matthieu Moy, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Mon, 14 Feb 2011, Marc Branchaud wrote: > For me, having more than one remote be *simultaneously* authoritative for a > set of tags is the unusual case. I find that most projects, no matter how > decentralized, need to agree upon the project's "official" history, and that > such agreement is almost always encapsulated within a single, "official" > repository. To have more than one is, frankly, insane. That's a social convention, and a pretty sane one indeed. BUT if this happens not to be the case (think of a project fork) then the tool must not get in the way if you happen to want to track both branches at the same time including their possibly conflicting set of tags. So having a separate namespace for tags coming from different remotes shouldn't make any difference to you when the tool can easily figure out that none of them conflicts with each other. > So to me it seems completely natural to think of a project's "official" tags > as the ones that are obtained from the project's "official" repository. It > follows that tags should subscribe to the same remote-ref model as branches. That's exactly what the proposal is about: making remote tags distinguishable per remote, just like branches are. > The benefits are powerful: consistency; deals naturally with imported > histories from different repositories; and allows automatic propagation of > updated (i.e. moved) tags from remotes to clones (yes tags *should* never > move, but they do, often for good reason and occasionally as part of a > project's natural evolution). Sure. But if you follow a single remote like most people do then you won't see the difference from the current state of affairs we have today. But if you do follow multiple remotes related to the same project, and one of them do move a tag, then you certainly want to be notified of it and then have the _choice_ of the actual remote you want to use for the tag meaning, and not having that tag become authoritative for all the remotes you track, especially if you may end up not agreeing with that move for some reasons. > There have been several comments disparaging per-remote tags, but people are > clearly dissatisfied with the status quo. Can anyone propose another > alternative? People have been disparaging the lack of explicit rename tracking in Git too. IMHO those people disparaging per-remote tags so far did not bring any serious solid technical reason for not doing it. Resistance so far appears to be based on a fear of change, which change is even not justified as people's workflow should remain completely unchanged in the presence of duplicate non-conflicting tags encouraged by current social conventions. Nicolas ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-14 9:40 ` [1.8.0] Provide proper remote ref namespaces Jakub Narebski 2011-02-14 15:45 ` Marc Branchaud @ 2011-02-14 18:30 ` Junio C Hamano 2011-02-14 19:06 ` Nicolas Pitre 1 sibling, 1 reply; 104+ messages in thread From: Junio C Hamano @ 2011-02-14 18:30 UTC (permalink / raw) To: Jakub Narebski Cc: Johan Herland, git, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre Jakub Narebski <jnareb@gmail.com> writes: > Please consider this use case: > > Let's assume that current maintainer steps aside for a bit, and new interim > temporary maintainer takes mantle. One would add new remote _temporarily_, > but one would want for tags that temporary maintainer created to be as good > as tags from 'origin' remote... and not be deleted when you remove temp > remote and its remote-tracking branches. Why don't you want to delete them? When the "interim" maintainer gives the baton back to the authoritative maintainer, the tags that are blessed between these two maintainers will surely be propagated [*1*] to the authoritative repository and you will have them at refs/tags or refs/remotes/origin/tags in your repository. And at that point, if you do not want to have refs/remotes/interim/heads/ branches, you surely do not mind cleaning refs/remotes/interim/tags/ hierarchy as well, no? Having said all that, if we assume *1* above, then we wouldn't have needed separate tag namespace in the first place. Further, think about the case where the "interim" maintainer ends up becoming the authoritative maintainer, which is the same thing as not assuming *1* above. You would want to consolidate refs/remotes/origin/tags and refs/remotes/interim/tags, and we do not expect any collisions when we do so. Which suggests that tags namespace is really special in that it does want to be globally unique and agreed namespace, unlike branch namespace. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-14 18:30 ` Junio C Hamano @ 2011-02-14 19:06 ` Nicolas Pitre 2011-02-14 19:46 ` Sverre Rabbelier 0 siblings, 1 reply; 104+ messages in thread From: Nicolas Pitre @ 2011-02-14 19:06 UTC (permalink / raw) To: Junio C Hamano Cc: Jakub Narebski, Johan Herland, git, Jeff King, Matthieu Moy, Dmitry Potapov, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Mon, 14 Feb 2011, Junio C Hamano wrote: > Jakub Narebski <jnareb@gmail.com> writes: > > > Please consider this use case: > > > > Let's assume that current maintainer steps aside for a bit, and new interim > > temporary maintainer takes mantle. One would add new remote _temporarily_, > > but one would want for tags that temporary maintainer created to be as good > > as tags from 'origin' remote... and not be deleted when you remove temp > > remote and its remote-tracking branches. > > Why don't you want to delete them? > > When the "interim" maintainer gives the baton back to the authoritative > maintainer, the tags that are blessed between these two maintainers will > surely be propagated [*1*] to the authoritative repository and you will > have them at refs/tags or refs/remotes/origin/tags in your repository. > > And at that point, if you do not want to have refs/remotes/interim/heads/ > branches, you surely do not mind cleaning refs/remotes/interim/tags/ > hierarchy as well, no? Exact. > Having said all that, if we assume *1* above, then we wouldn't have needed > separate tag namespace in the first place. Depends. There could be multiple compeeting "interim" maintainers effectively creating forks. They may have conflicting tags. The "official" maintainer may vet only one of those forks. The other forks may die or have a life of their own, Etc. Etc. > Further, think about the case where the "interim" maintainer ends up > becoming the authoritative maintainer, which is the same thing as not > assuming *1* above. You would want to consolidate refs/remotes/origin/tags > and refs/remotes/interim/tags, and we do not expect any collisions when we do > so. Right. But that's an expectation based on social practices within a project. In theory there _could_ be collisions. Let's take the OpenOffice vs LibreOffice as an example. What if I want both in my repository so I can easily perform diffs between those independent branches? They may certainly end up producing releases with the same version numbers (same tag name) but different content (different tag references). > Which suggests that tags namespace is really special in that it does want > to be globally unique and agreed namespace, unlike branch namespace. Semantically, yes. but a separate namespace just makes special cases as those shown above so much easier to deal with. The separate namespace is a _technical_ implementation detail that makes all the ambigous cases easy. It doesn't make the mistake of imposing a social convention upon people. So whatever people end up collectively doing with their tags is not tied to the tool's limitation anymore. You end up with 2 tags with the same name? Fine. If they are identical then you may just as well ignore that they're in separate namespaces. The tool will present things to you as such instead of enforcing that in the data structure (this is just like we do with file renames). If they're different, then at least you now have the possibility to choose which tag you actually want by prefixing it with its namespace. Right now this is just not possible. Please let's not confuse technical details like data (or tag) storage with social conventions. Nicolas ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-14 19:06 ` Nicolas Pitre @ 2011-02-14 19:46 ` Sverre Rabbelier 0 siblings, 0 replies; 104+ messages in thread From: Sverre Rabbelier @ 2011-02-14 19:46 UTC (permalink / raw) To: Nicolas Pitre Cc: Junio C Hamano, Jakub Narebski, Johan Herland, git, Jeff King, Matthieu Moy, Dmitry Potapov, Nguyen Thai Ngoc Duy Heya, On Mon, Feb 14, 2011 at 20:06, Nicolas Pitre <nico@fluxnic.net> wrote: > Let's take the OpenOffice vs LibreOffice as an example. What if I want > both in my repository so I can easily perform diffs between those > independent branches? They may certainly end up producing releases with > the same version numbers (same tag name) but different content > (different tag references). I think this concrete example of a very valid use case shows that we should (in some way or form) implement this :). -- Cheers, Sverre Rabbelier ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 3:51 ` Johan Herland 2011-02-07 5:11 ` Jeff King @ 2011-02-07 6:54 ` Matthieu Moy 1 sibling, 0 replies; 104+ messages in thread From: Matthieu Moy @ 2011-02-07 6:54 UTC (permalink / raw) To: Johan Herland Cc: git, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre Johan Herland <johan@herland.net> writes: > When you push to "remoteB", you would say "git push remoteB tag v1.7.4", and > it would resolve "v1.7.4" (via "refs/remotes/remoteA/tags/v1.7.4") into the > appropriate SHA-1, and then push the "v1.7.4" tag to the remote. That means I can fetch git-gui/v1.0, gitk/v1.1 and git/v1.7, my subproject tags are well sorted in my local repository, but if they don't have the same shortname, they're not "ambiguous", and the namespace will be completely flattened when I push (i.e. I'll push v1.0, v1.1 and v1.7, and people accessing my repository will not be able to say whether they refer to gitk, git-gui or git versions). This defeats the point in having proper namespaces, and we'll still see handmade namespaces like we already have now for git-gui tags in git.git. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 23:22 ` Johan Herland 2011-02-06 23:51 ` Matthieu Moy @ 2011-02-07 0:14 ` Dmitry Potapov 1 sibling, 0 replies; 104+ messages in thread From: Dmitry Potapov @ 2011-02-07 0:14 UTC (permalink / raw) To: Johan Herland Cc: git, Matthieu Moy, Junio C Hamano, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre On Mon, Feb 07, 2011 at 12:22:51AM +0100, Johan Herland wrote: > > As Nicolas mentioned elsewhere in the thread, having separate tag namespaces > does not prevent us from also warning about ambiguous tag names on fetch. > With separate namespaces, you could probably implement such a warning more > easily as a hook, instead of hacking the fetch code directly. Since when we started to handle the common case by forcing each user to write some hook (BTW, which one?), while having an uncommon case as the default? It makes no sense. And Nicolas suggested something different -- always warn on fetch, which means there will be warnings in your case where you have two projects in one repo. Dmitry ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-04 22:39 ` Junio C Hamano 2011-02-05 1:18 ` Johan Herland @ 2011-02-05 18:39 ` Nicolas Pitre 2011-02-05 19:37 ` Jeff King 1 sibling, 1 reply; 104+ messages in thread From: Nicolas Pitre @ 2011-02-05 18:39 UTC (permalink / raw) To: Junio C Hamano Cc: Johan Herland, git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy On Fri, 4 Feb 2011, Junio C Hamano wrote: > For some reason, many people seem to be enthused about splitting the tag > namespace, but I am not sure if that is a good thing in general. Branches > are moving pointers for people to flip around in their local repositories, > and it makes sense to say "My master is a bit ahead of the public one", > but what would we gain by making it _easier_ to add and exchange many tags > with the same name (e.g. refs/remotes/*/tags/v1.7.4 vs refs/tags/v1.7.4), > other than the extra confusion? The extraordinary misfeature of the tag namespace at the moment comes from the fact that whenever you add a remote repo to fetch, and do fetch it, then your flat tag namespace gets polluted with all the tags the remote might have. If you decide to delete some of those remote branches, the tags that came with it are still there and indistinguishable from other tags making it a real pain to sort out. So that's what has to be fixed. If you get duplicated tag names then just warn the user and give priority to the local one, or error out with a "ambiguous tag specification" if no local but multiple remote tags with the same name are found (the user would have to be more precise in the tag scope in that case). Nicolas ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-05 18:39 ` Nicolas Pitre @ 2011-02-05 19:37 ` Jeff King 2011-02-05 19:55 ` Nicolas Pitre 0 siblings, 1 reply; 104+ messages in thread From: Jeff King @ 2011-02-05 19:37 UTC (permalink / raw) To: Nicolas Pitre Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Sat, Feb 05, 2011 at 01:39:57PM -0500, Nicolas Pitre wrote: > So that's what has to be fixed. If you get duplicated tag names then > just warn the user and give priority to the local one, or error out with > a "ambiguous tag specification" if no local but multiple remote tags > with the same name are found (the user would have to be more precise in > the tag scope in that case). The latter seems like a regression for the common case of fetching from two upstreams. E.g., I usually pull from Junio, getting remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I pull from him, getting remotes/spearce/v1.7.0, which he previously fetched from Junio. Under the current code, I can still do "git show v1.7.0"; under the scheme described above I now have to say "origin/v1.7.0" to disambiguate. The real issue, I think, is that we are claiming ambiguity even though those tags almost certainly point to the same sha1. When handling ambiguous tags, should we perhaps check to see if all of the ambiguities point to the same sha1, and in that case, just pick one at random? In the case of resolving a ref to a sha1, then by definition they are all equivalent to pick. For things that care (e.g., "git checkout") we should probably still complain (although many of those commands have their own disambiguation code to prefer refs/heads/ or whatever anyway). -Peff ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-05 19:37 ` Jeff King @ 2011-02-05 19:55 ` Nicolas Pitre 2011-02-05 23:39 ` Johan Herland ` (2 more replies) 0 siblings, 3 replies; 104+ messages in thread From: Nicolas Pitre @ 2011-02-05 19:55 UTC (permalink / raw) To: Jeff King Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Sat, 5 Feb 2011, Jeff King wrote: > On Sat, Feb 05, 2011 at 01:39:57PM -0500, Nicolas Pitre wrote: > > > So that's what has to be fixed. If you get duplicated tag names then > > just warn the user and give priority to the local one, or error out with > > a "ambiguous tag specification" if no local but multiple remote tags > > with the same name are found (the user would have to be more precise in > > the tag scope in that case). > > The latter seems like a regression for the common case of fetching from > two upstreams. E.g., I usually pull from Junio, getting > remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I > pull from him, getting remotes/spearce/v1.7.0, which he previously > fetched from Junio. Under the current code, I can still do "git show > v1.7.0"; under the scheme described above I now have to say > "origin/v1.7.0" to disambiguate. Let's suppose that both tags are identical, as in your scenario above they would be, then there is no need to call for any ambiguity in that case. > The real issue, I think, is that we are claiming ambiguity even though > those tags almost certainly point to the same sha1. When handling > ambiguous tags, should we perhaps check to see if all of the ambiguities > point to the same sha1, and in that case, just pick one at random? If they're identical then there is no randomness. If they refer to different tag objects, even if those tag objects do refer to the same commit object, then I'd say there is an ambiguity only if the tag object content matters i.e. when displaying the tag content. > In the case of resolving a ref to a sha1, then by definition they are > all equivalent to pick. For things that care (e.g., "git checkout") we > should probably still complain (although many of those commands have > their own disambiguation code to prefer refs/heads/ or whatever anyway). We are probably more or less saying the same thing. Nicolas ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-05 19:55 ` Nicolas Pitre @ 2011-02-05 23:39 ` Johan Herland 2011-02-06 20:04 ` Junio C Hamano 2011-02-07 5:18 ` Jeff King 2 siblings, 0 replies; 104+ messages in thread From: Johan Herland @ 2011-02-05 23:39 UTC (permalink / raw) To: git Cc: Nicolas Pitre, Jeff King, Junio C Hamano, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Saturday 05 February 2011, Nicolas Pitre wrote: > On Sat, 5 Feb 2011, Jeff King wrote: > > On Sat, Feb 05, 2011 at 01:39:57PM -0500, Nicolas Pitre wrote: > > > So that's what has to be fixed. If you get duplicated tag names then > > > just warn the user and give priority to the local one, or error out > > > with a "ambiguous tag specification" if no local but multiple remote > > > tags with the same name are found (the user would have to be more > > > precise in the tag scope in that case). > > > > The latter seems like a regression for the common case of fetching from > > two upstreams. E.g., I usually pull from Junio, getting > > remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I > > pull from him, getting remotes/spearce/v1.7.0, which he previously > > fetched from Junio. Under the current code, I can still do "git show > > v1.7.0"; under the scheme described above I now have to say > > "origin/v1.7.0" to disambiguate. > > Let's suppose that both tags are identical, as in your scenario above > they would be, then there is no need to call for any ambiguity in that > case. > > > The real issue, I think, is that we are claiming ambiguity even though > > those tags almost certainly point to the same sha1. When handling > > ambiguous tags, should we perhaps check to see if all of the > > ambiguities point to the same sha1, and in that case, just pick one at > > random? > > If they're identical then there is no randomness. If they refer to > different tag objects, even if those tag objects do refer to the same > commit object, then I'd say there is an ambiguity only if the tag object > content matters i.e. when displaying the tag content. > > > In the case of resolving a ref to a sha1, then by definition they are > > all equivalent to pick. For things that care (e.g., "git checkout") we > > should probably still complain (although many of those commands have > > their own disambiguation code to prefer refs/heads/ or whatever > > anyway). > > We are probably more or less saying the same thing. Yes, I believe this was all covered by a footnote in my proposal. Quote: [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local tag (refs/tags/v1.7.4) is found, then we have an unambiguous match. If no local tag is found, we look up the tag name in all configured remotes (using the method described in [1]). If the tag name exists in one or more remotes, and those remotes all agree on its ultimate object name (after applying e.g. ^{commit} or whatever is appropriate in the context of the lookup), then we also have an unambiguous match. However, if the tag name exists in multiple remotes, and they do NOT all agree on its ultimate object name, then the shorthand tag name is ambiguous and the lookup fails. The user can always resolve this ambiguity by creating a local tag (refs/tags/v1.7.4) pointing to the desired object. Have fun! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-05 19:55 ` Nicolas Pitre 2011-02-05 23:39 ` Johan Herland @ 2011-02-06 20:04 ` Junio C Hamano 2011-02-07 16:10 ` Marc Branchaud 2011-02-07 5:18 ` Jeff King 2 siblings, 1 reply; 104+ messages in thread From: Junio C Hamano @ 2011-02-06 20:04 UTC (permalink / raw) To: Nicolas Pitre Cc: Jeff King, Junio C Hamano, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy Nicolas Pitre <nico@fluxnic.net> writes: >> The latter seems like a regression for the common case of fetching from >> two upstreams. E.g., I usually pull from Junio, getting >> remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I >> pull from him, getting remotes/spearce/v1.7.0, which he previously >> fetched from Junio. Under the current code, I can still do "git show >> v1.7.0"; under the scheme described above I now have to say >> "origin/v1.7.0" to disambiguate. > > Let's suppose that both tags are identical, as in your scenario above > they would be, then there is no need to call for any ambiguity in that > case. I agree that we do not want refs/remotes/tags/*/that-tag-people-agree-on in that case. We want to store a single copy and find it there, and that single copy has traditionally been found in refs/tags hierarchy. I think the real issue is not necessarily that the location is shared with local tag namespace, but is the lack of a convenient way (or just BCP) to segregate what are local and what are official when transferring tags out of your repository. That is what discourages people from using tags for their personal and ephemeral use, marking some points in their own work with personal tags that are never intended to be published. In the "interim maintainer" case without separate tag namespaces, Shawn would have been using refs/tags space to auto-follow vX.Y.Z tags that everybody agrees on and also mark his own progress with local tags, and he needs to be careful not to push out the local tags he does not want to share to his publishing repository, lest he contaminate refs/tags in repositories of other people [*1*] But the above is less of an issue, for people who use a separate publish repository with private working repository. All they need to do is to be careful when they run "git push". By default we don't push new tags (thanks to "matching refs") nor push autopropagates tags when pushing updated branch heads out, so it suffices only to double check the tag being pushed is the right one when they run "git push $there vX.Y.Z", and to make sure they never run "git push --tags". The problem happens when people directly start fetching or cloning from a private working-space repository, e.g. my primary integration repository has several tags that shouldn't go to k.org mixed with the vX.Y.Z tags, and that is perfectly fine as the organization gives me a uniform way to call things with names without looking at many places (i.e. refs/tags vs refs/remotes/*/tags/), yet it does not risk contaminating other people's tag namespaces because I don't allow anybody to clone nor fetch from it directly. That breaks down once people can fetch/clone from it. Thinking aloud and not thinking things through, perhaps what's needed is a namespace private/local to the repository, i.e. instead of refs/remotes/*/tags, refs/private-tags hierarchy that I can use to store local names, and are never seen by fetch/clone? You can swap naming around and say my (refs/tags, refs/private-tags) can be expressed with (refs/remotes/origin/tags, refs/tags), and I fully agree with that argument. The former is for tags everybody agrees on, the latter for tags that are private. The aversion I showed in my message against refs/remotes/*/tags is coming directly from this observation. Namely, you can explain refs/remotes/origin/tags with the above line of reasoning, but how would you explain refs/remotes/$other_names/tags hierarchy? What do they mean, how they are useful, etc. [Footnote] *1* This issue actually is already present without "interim maintainer". I have several tags in my primary integration repository that I don't intend to publish to my repository at k.org; the gitster/git.git repository I have at GitHub is intended to disclose what I personally have, including the broken-out set of topic branches, and these tags are published there. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-06 20:04 ` Junio C Hamano @ 2011-02-07 16:10 ` Marc Branchaud 2011-02-07 19:40 ` Junio C Hamano 0 siblings, 1 reply; 104+ messages in thread From: Marc Branchaud @ 2011-02-07 16:10 UTC (permalink / raw) To: Junio C Hamano Cc: Nicolas Pitre, Jeff King, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy On 11-02-06 03:04 PM, Junio C Hamano wrote: > Nicolas Pitre <nico@fluxnic.net> writes: > >>> The latter seems like a regression for the common case of fetching from >>> two upstreams. E.g., I usually pull from Junio, getting >>> remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I >>> pull from him, getting remotes/spearce/v1.7.0, which he previously >>> fetched from Junio. Under the current code, I can still do "git show >>> v1.7.0"; under the scheme described above I now have to say >>> "origin/v1.7.0" to disambiguate. >> >> Let's suppose that both tags are identical, as in your scenario above >> they would be, then there is no need to call for any ambiguity in that >> case. > > I agree that we do not want refs/remotes/tags/*/that-tag-people-agree-on > in that case. We want to store a single copy and find it there, and that > single copy has traditionally been found in refs/tags hierarchy. > > I think the real issue is not necessarily that the location is shared with > local tag namespace, but is the lack of a convenient way (or just BCP) to > segregate what are local and what are official when transferring tags out > of your repository. That is what discourages people from using tags for > their personal and ephemeral use, marking some points in their own work > with personal tags that are never intended to be published. That may be an issue, but I don't think it's the issue in this thread. Recall what Nicolas said: The extraordinary misfeature of the tag namespace at the moment comes from the fact that whenever you add a remote repo to fetch, and do fetch it, then your flat tag namespace gets polluted with all the tags the remote might have. If you decide to delete some of those remote branches, the tags that came with it are still there and indistinguishable from other tags making it a real pain to sort out. Those tags can all be properly "official" and still the problem exists. In the "interim maintainer" case, I suggest it's not really a question of private-vs-official tags. Folks who clone directly from the maintainer should understand that some tags are works-in-progress. As the maintainer role gets passed from person to person (and repo to repo), it seems more useful to be able to distinguish work-in-progress tag vX.Y.Z as coming from maintainer A or B, i.e. tags A/vX.Y.Z and B/vX.Y.Z. If the tags point to the same commit then just "vX.Y.Z" resolves fine. But if the two maintainers have different ideas of what vX.Y.Z should be, then the fully-qualified names help to identify the differences. Tags don't become "official" until they're published according to the project's process. For us git users, that means the tag appears in git.kernel.org/pub/scm/git/git.git. A tag that appears somewhere else can have all sorts of meanings, but I don't think "official" could be one of them. M. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 16:10 ` Marc Branchaud @ 2011-02-07 19:40 ` Junio C Hamano 2011-02-07 20:37 ` Nicolas Pitre 0 siblings, 1 reply; 104+ messages in thread From: Junio C Hamano @ 2011-02-07 19:40 UTC (permalink / raw) To: Marc Branchaud Cc: Junio C Hamano, Nicolas Pitre, Jeff King, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy Marc Branchaud <marcnarc@xiplink.com> writes: > Tags don't become "official" until they're published according to the > project's process. For us git users, that means the tag appears in > git.kernel.org/pub/scm/git/git.git. A tag that appears somewhere else can > have all sorts of meanings, but I don't think "official" could be one of them. I think you are essentially saying the same thing. Think of hiding the unofficial tags to refs/private-tags by "interim maintainer" (or public at large for that matter); they won't be published automatically, unless the publisher decides to publish "according to the project's process." As I said in my message, it feels awkward to use refs/private-tags for tags everybody uses for his or her own purpose, so by swapping the roles of namespaces around, we would be able to use refs/tags for private ones, and refs/remotes/origin/tags for the ones that came from upstream. But then if you fetch/pull from a third party (including the "interim maintainer"), it feels wasteful to get full set of tags that you have in the origin namespace anyway replicated in refs/remotes/interim/tags. And that is what bothers me---not the waste itself, but I have this nagging feeling that the wasteful duplication is an indication of something else designed wrong. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 19:40 ` Junio C Hamano @ 2011-02-07 20:37 ` Nicolas Pitre 0 siblings, 0 replies; 104+ messages in thread From: Nicolas Pitre @ 2011-02-07 20:37 UTC (permalink / raw) To: Junio C Hamano Cc: Marc Branchaud, Jeff King, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Mon, 7 Feb 2011, Junio C Hamano wrote: > As I said in my message, it feels awkward to use refs/private-tags for > tags everybody uses for his or her own purpose, so by swapping the roles > of namespaces around, we would be able to use refs/tags for private ones, > and refs/remotes/origin/tags for the ones that came from upstream. But > then if you fetch/pull from a third party (including the "interim > maintainer"), it feels wasteful to get full set of tags that you have in > the origin namespace anyway replicated in refs/remotes/interim/tags. Why so? At least you get to know if that particular remote has a particular tag that may also exist elsewhere. And if you decide to drop one remote source with all its tags from your local repository, then the remaining one(s) still have relevant tags available. > And that is what bothers me---not the waste itself, but I have this > nagging feeling that the wasteful duplication is an indication of > something else designed wrong. We do have "wasteful" duplicated references all over the place, such as when two directories (tree objects) contain the same file content (refer to the same blob object). But no one feels like this is wasted duplication as those two directories end up using the same single blob object even if in the working directory you get twice the content. Here this is the same thing. You have multiple handles to the same tag which are distributed across different remote repositoryes you are tracking. The name on the tag may be found in many places, and even under different names. But there is still only one actual tag object. If you have 3 remotes sharing the same tag then you know that the tag cannot be garbage collected until all three remotes have been removed from your repository. Simply storing snapshots of the tag state per remote repository is simple and allow for smarter processing on top, which is in agreement with the design philosophy for the rest of Git. Nicolas ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-05 19:55 ` Nicolas Pitre 2011-02-05 23:39 ` Johan Herland 2011-02-06 20:04 ` Junio C Hamano @ 2011-02-07 5:18 ` Jeff King 2011-02-07 14:53 ` Nicolas Pitre 2 siblings, 1 reply; 104+ messages in thread From: Jeff King @ 2011-02-07 5:18 UTC (permalink / raw) To: Nicolas Pitre Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Sat, Feb 05, 2011 at 02:55:06PM -0500, Nicolas Pitre wrote: > > The latter seems like a regression for the common case of fetching from > > two upstreams. E.g., I usually pull from Junio, getting > > remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I > > pull from him, getting remotes/spearce/v1.7.0, which he previously > > fetched from Junio. Under the current code, I can still do "git show > > v1.7.0"; under the scheme described above I now have to say > > "origin/v1.7.0" to disambiguate. > > Let's suppose that both tags are identical, as in your scenario above > they would be, then there is no need to call for any ambiguity in that > case. Agreed, but... > > The real issue, I think, is that we are claiming ambiguity even though > > those tags almost certainly point to the same sha1. When handling > > ambiguous tags, should we perhaps check to see if all of the ambiguities > > point to the same sha1, and in that case, just pick one at random? > > If they're identical then there is no randomness. If they refer to > different tag objects, even if those tag objects do refer to the same > commit object, then I'd say there is an ambiguity only if the tag object > content matters i.e. when displaying the tag content. My gut feeling is that they should point to the same tag object, for the sake of simplicity (if you are re-tagging a commit under the same name, wouldn't I want to know?) and efficiency (we can detect non-ambiguity just by looking at the sha1 values without opening objects). But more importantly, don't we sometimes care where the ref came from? If I say "git push remote v1.7.4" we do some automagic on the destination side of the refspec based on the fact that the source ref was found in the refs/tags hierarchy. In the case we're talking about, all of the ambiguous refs would presumably also be coming from refs/remotes/*/tags/, so they would be functionally equivalent. But I wanted to point it out because: 1. It is an additional equivalent requirement for two refs to not be ambiguous. They must have the same sha1, _and_ they must have the same "type". 2. I couldn't think of any other cases where the actual refname might matter and this would break. But I wanted to bring it up explicitly in case somebody else can think of one. -Peff ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 5:18 ` Jeff King @ 2011-02-07 14:53 ` Nicolas Pitre 2011-02-07 20:25 ` Jeff King 0 siblings, 1 reply; 104+ messages in thread From: Nicolas Pitre @ 2011-02-07 14:53 UTC (permalink / raw) To: Jeff King Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Mon, 7 Feb 2011, Jeff King wrote: > On Sat, Feb 05, 2011 at 02:55:06PM -0500, Nicolas Pitre wrote: > > > > The latter seems like a regression for the common case of fetching from > > > two upstreams. E.g., I usually pull from Junio, getting > > > remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I > > > pull from him, getting remotes/spearce/v1.7.0, which he previously > > > fetched from Junio. Under the current code, I can still do "git show > > > v1.7.0"; under the scheme described above I now have to say > > > "origin/v1.7.0" to disambiguate. > > > > Let's suppose that both tags are identical, as in your scenario above > > they would be, then there is no need to call for any ambiguity in that > > case. > > Agreed, but... > > > > The real issue, I think, is that we are claiming ambiguity even though > > > those tags almost certainly point to the same sha1. When handling > > > ambiguous tags, should we perhaps check to see if all of the ambiguities > > > point to the same sha1, and in that case, just pick one at random? > > > > If they're identical then there is no randomness. If they refer to > > different tag objects, even if those tag objects do refer to the same > > commit object, then I'd say there is an ambiguity only if the tag object > > content matters i.e. when displaying the tag content. > > My gut feeling is that they should point to the same tag object, for the > sake of simplicity (if you are re-tagging a commit under the same name, > wouldn't I want to know?) and efficiency (we can detect non-ambiguity > just by looking at the sha1 values without opening objects). Agreed. Same tag name referring to same commit but with different tag objects is a bit silly and trying to make that case non ambiguous is probably going to cause more confusion anyway. If the tag object is different then this is for most purposes a different tag. > But more importantly, don't we sometimes care where the ref came from? Not at the moment. Certainly not with the current flat namespace used for tags. > If I say "git push remote v1.7.4" we do some automagic on the > destination side of the refspec based on the fact that the source ref > was found in the refs/tags hierarchy. In the case we're talking about, > all of the ambiguous refs would presumably also be coming from > refs/remotes/*/tags/, so they would be functionally equivalent. But I > wanted to point it out because: > > 1. It is an additional equivalent requirement for two refs to not be > ambiguous. They must have the same sha1, _and_ they must have the > same "type". How can this matter? The same automagic on the destination ref may still take place. Semantically you want to push v1.7.4 so nothing has to change there, irrespective of the namespace the v1.7.4 tag comes from. This doesn't matter today, so why would this particular case need to change? Nicolas ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 14:53 ` Nicolas Pitre @ 2011-02-07 20:25 ` Jeff King 2011-02-07 20:51 ` Nicolas Pitre 0 siblings, 1 reply; 104+ messages in thread From: Jeff King @ 2011-02-07 20:25 UTC (permalink / raw) To: Nicolas Pitre Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Mon, Feb 07, 2011 at 09:53:29AM -0500, Nicolas Pitre wrote: > > But more importantly, don't we sometimes care where the ref came from? > > Not at the moment. Certainly not with the current flat namespace used > for tags. I'm not sure I was clear. I didn't mean "which remote the ref came from" but rather "when choosing between two refs, don't we sometimes care about the actual name of the ref?". But see below. > > If I say "git push remote v1.7.4" we do some automagic on the > > destination side of the refspec based on the fact that the source ref > > was found in the refs/tags hierarchy. In the case we're talking about, > > all of the ambiguous refs would presumably also be coming from > > refs/remotes/*/tags/, so they would be functionally equivalent. But I > > wanted to point it out because: > > > > 1. It is an additional equivalent requirement for two refs to not be > > ambiguous. They must have the same sha1, _and_ they must have the > > same "type". > > How can this matter? The same automagic on the destination ref may > still take place. Semantically you want to push v1.7.4 so nothing has > to change there, irrespective of the namespace the v1.7.4 tag comes > from. This doesn't matter today, so why would this particular case need > to change? I guess the problem is that I'm not clear on exactly what the new lookup / ambiguity rules are proposed to be. Clearly something will need to go in the dwim_ref level. And I think it's obvious that if "refs/tags/foo" and "refs/remotes/*/tags/foo" point to the same sha1, they will not be considered ambiguous. Will the same apply to refs/heads/foo versus refs/remotes/*/foo? Will it also apply to refs/heads/foo versus refs/remotes/*/tags/foo? In the final case, that does matter to "git push" (should the destination be in the head or tag namespace?). So the actual names of the ref can matter, and should probably be taken into account when deciding what is ambiguous. Maybe that was obvious to everybody and it was an implicit part of the proposal, but it wasn't clear to me. -Peff ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 20:25 ` Jeff King @ 2011-02-07 20:51 ` Nicolas Pitre 2011-02-07 20:56 ` Jeff King 0 siblings, 1 reply; 104+ messages in thread From: Nicolas Pitre @ 2011-02-07 20:51 UTC (permalink / raw) To: Jeff King Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Mon, 7 Feb 2011, Jeff King wrote: > I guess the problem is that I'm not clear on exactly what the new lookup > / ambiguity rules are proposed to be. Clearly something will need to go > in the dwim_ref level. And I think it's obvious that if "refs/tags/foo" > and "refs/remotes/*/tags/foo" point to the same sha1, they will not be > considered ambiguous. Agreed. > Will the same apply to refs/heads/foo versus refs/remotes/*/foo? I think it should. If both branches are pointing to the same commit then the short form "foo" should be unambigous and the operation proceed (be that 'git push' or 'git log' that shouldn't matter). > Will it > also apply to refs/heads/foo versus refs/remotes/*/tags/foo? In the > final case, that does matter to "git push" (should the destination be in > the head or tag namespace?). In such a case I'd say that head refs have precedence over tag refs, and when that occurs then warn the user. And I wouldn't make a special case for 'git push' here. Whether it is push or log, the head ref would take precedence, and the user warned about existence of a tag with the same name. Of course using "tag/foo" should be unambigous again. > So the actual names of the ref can matter, > and should probably be taken into account when deciding what is > ambiguous. What happens today when you have refs/heads/foo and refs/tags/foo? Nicolas ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Provide proper remote ref namespaces 2011-02-07 20:51 ` Nicolas Pitre @ 2011-02-07 20:56 ` Jeff King 0 siblings, 0 replies; 104+ messages in thread From: Jeff King @ 2011-02-07 20:56 UTC (permalink / raw) To: Nicolas Pitre Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier, Nguyen Thai Ngoc Duy On Mon, Feb 07, 2011 at 03:51:55PM -0500, Nicolas Pitre wrote: > > Will it > > also apply to refs/heads/foo versus refs/remotes/*/tags/foo? In the > > final case, that does matter to "git push" (should the destination be in > > the head or tag namespace?). > > In such a case I'd say that head refs have precedence over tag refs, and > when that occurs then warn the user. And I wouldn't make a special > case for 'git push' here. Whether it is push or log, the head ref would > take precedence, and the user warned about existence of a tag with the > same name. Of course using "tag/foo" should be unambigous again. I am fine with that, although it is the opposite of the current dwim_ref behavior (which warns on ambiguity but prefers tags). However, Junio has said that the current behavior was simply arbitrary. > > So the actual names of the ref can matter, > > and should probably be taken into account when deciding what is > > ambiguous. > > What happens today when you have refs/heads/foo and refs/tags/foo? For dwim_ref, it prefers the tag and issues a warning. For git-push, it complains about the ambiguity and dies. For git checkout, we prefer the head. For git-tag, we prefer the tag (though I think that only matters for "git tag -d"). -Peff ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [1.8.0] Remote tag namespace 2011-02-01 18:14 ` Jeff King 2011-02-01 23:14 ` Sverre Rabbelier @ 2011-02-01 23:15 ` Johan Herland 1 sibling, 0 replies; 104+ messages in thread From: Johan Herland @ 2011-02-01 23:15 UTC (permalink / raw) To: Jeff King; +Cc: git, Nguyen Thai Ngoc Duy, Nicolas Pitre On Tuesday 01 February 2011, Jeff King wrote: > On Tue, Feb 01, 2011 at 05:44:50PM +0700, Nguyen Thai Ngoc Duy wrote: > > OK I'm not familiar with tag code, but I can try. > > > > Proposal: > > > > Reserve refs/remote-tags namespace to store tags from remotes. Its > > structure is the same as in refs/remotes. When pulling tags, put them > > in refs/remote-tags/<remote> instead of refs/tags. > > Tag dereference code will be taught about refs/remote-tags with > > similar deref order as in remote branches. > > There are similar questions around remote notes refs. Should there also > be a refs/remote-notes? And there was some discussion recently about > fetching remote replace refs. > > Should we perhaps be massaging refs/remotes into a structure to handle > all of these things? Like: > > refs/remotes/origin/HEAD (-> refs/remotes/origin/heads/master) > refs/remotes/origin/heads/master > refs/remotes/origin/tags/v1.7.4 > refs/remotes/origin/notes/commit > refs/remotes/origin/replace/f67e92af477a2255b64a1ece33d9d126e763fe9b > > i.e., make refs/remotes/* an actual mirror of selected parts of the > remote's refs/ hierarchy. And then figure out sane rules for merging > those namespaces into the ref lookup procedure. For heads and tags, > probably some tweaking of the lookup rules in dwim_ref; for > replacements, probably you would want to manually say "I am interested > in this replace" and copy or symref-link it into your refs/ hierarchy. I fully agree. In addition - as discussed in http://thread.gmane.org/gmane.comp.version- control.git/160503/focus=160795 - we should also tweak the refspec format to make tag auto-following explicit in the refspec. > And probably something similar with notes. (going slightly offtopic with the notes discussion here) I've been thinking that notes should be organized much in the same fashion as branches/heads. There should be remote notes refs that should only be updated from the remote, and there should be local notes refs in refs/notes/*. You should be able to configure upstream relationships between local notes refs and remote notes refs (e.g. notes.foo.remote and notes.foo.merge), and auto-merge them on "git notes pull". Have fun! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 104+ messages in thread
end of thread, other threads:[~2011-02-18 0:57 UTC | newest] Thread overview: 104+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-01 10:44 [1.8.0] Remote tag namespace Nguyen Thai Ngoc Duy 2011-02-01 14:10 ` Leo Razoumov 2011-02-01 15:07 ` Marc Branchaud 2011-02-01 15:35 ` Nguyen Thai Ngoc Duy 2011-02-02 19:38 ` Marc Branchaud 2011-02-01 18:14 ` Jeff King 2011-02-01 23:14 ` Sverre Rabbelier 2011-02-02 2:21 ` [1.8.0] Provide proper remote ref namespaces Johan Herland 2011-02-02 13:27 ` Santi Béjar 2011-02-02 15:51 ` Johan Herland 2011-02-02 16:19 ` Santi Béjar 2011-02-03 5:33 ` Nguyen Thai Ngoc Duy 2011-02-03 8:46 ` Johan Herland 2011-02-03 11:35 ` Nguyen Thai Ngoc Duy 2011-02-03 13:10 ` Johan Herland 2011-02-03 14:10 ` Santi Béjar 2011-02-03 15:48 ` Nguyen Thai Ngoc Duy 2011-02-04 22:39 ` Junio C Hamano 2011-02-05 1:18 ` Johan Herland 2011-02-05 18:00 ` Kevin P. Fleming 2011-02-05 21:40 ` Dmitry Potapov 2011-02-06 0:04 ` Johan Herland 2011-02-06 12:03 ` Dmitry Potapov 2011-02-06 14:09 ` Nicolas Pitre 2011-02-06 15:17 ` Dmitry Potapov 2011-02-06 16:11 ` Johan Herland 2011-02-06 17:28 ` Dmitry Potapov 2011-02-06 22:12 ` Johan Herland 2011-02-07 0:07 ` Dmitry Potapov 2011-02-07 19:05 ` Bernhard R. Link 2011-02-08 1:20 ` Dmitry Potapov [not found] ` <201102070429.05033.johan@herland.net> 2011-02-07 3:47 ` Nicolas Pitre 2011-02-08 1:06 ` Dmitry Potapov 2011-02-08 8:15 ` Johan Herland 2011-02-08 19:11 ` Enrico Weigelt 2011-02-08 23:13 ` Junio C Hamano 2011-02-09 1:24 ` Johan Herland 2011-02-06 20:28 ` Matthieu Moy 2011-02-06 23:22 ` Johan Herland 2011-02-06 23:51 ` Matthieu Moy 2011-02-07 3:51 ` Johan Herland 2011-02-07 5:11 ` Jeff King 2011-02-07 8:58 ` Johan Herland 2011-02-07 9:01 ` Sverre Rabbelier 2011-02-07 10:06 ` Johan Herland 2011-02-07 10:22 ` Nguyen Thai Ngoc Duy 2011-02-07 20:19 ` Jeff King 2011-02-08 0:59 ` Johan Herland 2011-02-11 15:13 ` Jakub Narebski 2011-02-13 23:36 ` Johan Herland 2011-02-14 7:35 ` Junio C Hamano 2011-02-14 9:18 ` Johan Herland 2011-02-14 9:59 ` Jakub Narebski 2011-02-14 17:30 ` Junio C Hamano 2011-02-14 18:06 ` Re* " Junio C Hamano 2011-02-14 18:53 ` Jay Soffian 2011-02-14 19:44 ` Sverre Rabbelier 2011-02-14 19:50 ` Jay Soffian 2011-02-14 21:21 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder 2011-02-14 21:41 ` Jay Soffian 2011-02-14 21:55 ` Jonathan Nieder 2011-02-14 21:57 ` Re* [1.8.0] Provide proper remote ref namespaces Matthieu Moy 2011-02-14 22:35 ` Jeff King 2011-02-14 22:38 ` Sverre Rabbelier 2011-02-14 23:36 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder 2011-02-14 23:45 ` Re* [1.8.0] Provide proper remote ref namespaces Junio C Hamano 2011-02-14 23:05 ` Junio C Hamano 2011-02-15 15:06 ` Johan Herland 2011-02-15 18:06 ` Junio C Hamano 2011-02-16 0:54 ` [PATCH] push.default: Rename 'tracking' to 'upstream' Johan Herland 2011-02-16 6:35 ` Junio C Hamano 2011-02-16 8:55 ` Matthieu Moy 2011-02-16 9:42 ` Martin von Zweigbergk 2011-02-16 10:08 ` Jakub Narebski 2011-02-16 10:26 ` Matthieu Moy 2011-02-16 10:27 ` Sverre Rabbelier 2011-02-16 17:56 ` Junio C Hamano 2011-02-16 18:08 ` Sverre Rabbelier 2011-02-16 18:37 ` Junio C Hamano 2011-02-18 0:51 ` Martin von Zweigbergk 2011-02-18 0:57 ` Martin von Zweigbergk 2011-02-16 10:54 ` Bernhard R. Link 2011-02-14 9:40 ` [1.8.0] Provide proper remote ref namespaces Jakub Narebski 2011-02-14 15:45 ` Marc Branchaud 2011-02-14 19:35 ` Nicolas Pitre 2011-02-14 18:30 ` Junio C Hamano 2011-02-14 19:06 ` Nicolas Pitre 2011-02-14 19:46 ` Sverre Rabbelier 2011-02-07 6:54 ` Matthieu Moy 2011-02-07 0:14 ` Dmitry Potapov 2011-02-05 18:39 ` Nicolas Pitre 2011-02-05 19:37 ` Jeff King 2011-02-05 19:55 ` Nicolas Pitre 2011-02-05 23:39 ` Johan Herland 2011-02-06 20:04 ` Junio C Hamano 2011-02-07 16:10 ` Marc Branchaud 2011-02-07 19:40 ` Junio C Hamano 2011-02-07 20:37 ` Nicolas Pitre 2011-02-07 5:18 ` Jeff King 2011-02-07 14:53 ` Nicolas Pitre 2011-02-07 20:25 ` Jeff King 2011-02-07 20:51 ` Nicolas Pitre 2011-02-07 20:56 ` Jeff King 2011-02-01 23:15 ` [1.8.0] Remote tag namespace Johan Herland
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.