[1.8.0] Remote tag namespace

[1.8.0] Remote tag namespace

[Nguyen Thai Ngoc Duy]

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

Re: [1.8.0] Remote tag namespace

[Leo Razoumov]

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--

Re: [1.8.0] Remote tag namespace

[Marc Branchaud]

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.

Re: [1.8.0] Remote tag namespace

[Nguyen Thai Ngoc Duy]

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

Re: [1.8.0] Remote tag namespace

[Jeff King]

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

Re: [1.8.0] Remote tag namespace

[Sverre Rabbelier]

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

Re: [1.8.0] Remote tag namespace

[Johan Herland]

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

[1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Santi Béjar]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Santi Béjar]

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

Re: [1.8.0] Remote tag namespace

[Marc Branchaud]

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.

Re: [1.8.0] Provide proper remote ref namespaces

[Nguyen Thai Ngoc Duy]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Nguyen Thai Ngoc Duy]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Santi Béjar]

> 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

Re: [1.8.0] Provide proper remote ref namespaces

[Nguyen Thai Ngoc Duy]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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.

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Kevin P. Fleming]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Jeff King]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Dmitry Potapov]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Dmitry Potapov]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Dmitry Potapov]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Dmitry Potapov]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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.

Re: [1.8.0] Provide proper remote ref namespaces

[Matthieu Moy]

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/

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

(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

Re: [1.8.0] Provide proper remote ref namespaces

[Matthieu Moy]

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/

Re: [1.8.0] Provide proper remote ref namespaces

[Dmitry Potapov]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Dmitry Potapov]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Jeff King]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Jeff King]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Matthieu Moy]

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/

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Sverre Rabbelier]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Nguyen Thai Ngoc Duy]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Marc Branchaud]

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.

Re: [1.8.0] Provide proper remote ref namespaces

[Bernhard R. Link]

* 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

Re: [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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.

Re: [1.8.0] Provide proper remote ref namespaces

[Jeff King]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Jeff King]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Jeff King]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Dmitry Potapov]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Dmitry Potapov]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Enrico Weigelt]

* 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
----------------------------------------------------------------------

Re: [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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....

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Jakub Narebski]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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.

Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Jakub Narebski]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Jakub Narebski]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Marc Branchaud]

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.

Re: [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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.

Re* [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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.

Re: Re* [1.8.0] Provide proper remote ref namespaces

[Jay Soffian]

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.

Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre]

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

Re: Re* [1.8.0] Provide proper remote ref namespaces

[Sverre Rabbelier]

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

Re: [1.8.0] Provide proper remote ref namespaces

[Sverre Rabbelier]

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

Re: Re* [1.8.0] Provide proper remote ref namespaces

[Jay Soffian]

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.

Re: [1.8.0 RFC] push: start warning upcoming default change for push.default

[Jonathan Nieder]

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.

Re: [1.8.0 RFC] push: start warning upcoming default change for push.default

[Jay Soffian]

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.

Re: [1.8.0 RFC] push: start warning upcoming default change for push.default

[Jonathan Nieder]

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?

Re: Re* [1.8.0] Provide proper remote ref namespaces

[Matthieu Moy]

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/

Re: Re* [1.8.0] Provide proper remote ref namespaces

[Jeff King]

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

Re: Re* [1.8.0] Provide proper remote ref namespaces

[Sverre Rabbelier]

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

Re: Re* [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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.

Re: [1.8.0 RFC] push: start warning upcoming default change for push.default

[Jonathan Nieder]

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.

Re: Re* [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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?

Re: Re* [1.8.0] Provide proper remote ref namespaces

[Johan Herland]

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

Re: Re* [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano]

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?

[PATCH] push.default: Rename 'tracking' to 'upstream'

[Johan Herland]

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

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Junio C Hamano]

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.

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Matthieu Moy]

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/

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Martin von Zweigbergk]

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

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Jakub Narebski]

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

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Matthieu Moy]

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/

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Sverre Rabbelier]

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

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Bernhard R. Link]

* 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

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Junio C Hamano]

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.

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Sverre Rabbelier]

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

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Junio C Hamano]

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.

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Martin von Zweigbergk]

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.

Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

[Martin von Zweigbergk]

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