Re: [1.8.0] Provide proper remote ref namespaces

[Marc Branchaud <marcnarc@xiplink.com>]

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.