Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre <nico@fluxnic.net>]

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