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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html