On Thursday 04 November 2010, Marc Branchaud wrote: > On 10-11-03 08:49 PM, Johan Herland wrote: > > I'd probably suggest a more straightforward (and hopefully less > > confusing) > > > > setup like this: > > Remote repo -> Local repo > > ------------------------------------------------ > > refs/heads/* refs/remotes/$remote/heads/* > > refs/tags/* refs/remotes/$remote/tags/* > > refs/notes/* refs/remotes/$remote/notes/* > > > > ...and these would all be set in the config, i.e. no implicit/magic > > refspecs. > > I'll second this proposal, at least as far as tags go. I can offer two > reasons to support this. > > > First, I think the assumption that tags are immutable is too strong. In > our repo, we try to keep our topic branches mergeable into both the > "master" and "maintenance-of-the-latest-release" branches. > > This means the topic branches need to be based at the point where the > maintenance and master branches diverged. Making this rule easy to > follow is best accomplished with a tag, e.g. "topic-base", but that tag > will move when we create a new maintenance branch for a new release. > With the current tag semantics, when that happens everyone has to delete > their local topic-base tags and get the new one from the common/shared > repo. People who forget to do this end up basing their topics on > outdated code, with predictable results. > > It would be much easier to be able to just use an "origin/topic-base" tag > instead, one that that tracks the topic-base tag in the origin repo. Actually, this is not a valid reason. To me, it sounds like your "topic- base" tag _really_ should be a "topic_base" _branch_. The branch is initialized to the merge-base between "master" and "maintenance-of-the- latest-release" branches, and when you create a new maintenance branch, the "topic-base" branch is fast-forwarded along the master branch until it reaches the merge-base with the new maintenance branch. (Remember that branches really are nothing but named pointers into the commit graph, and as long as the "topic-base" branch stays within the history of the "master" branch, it does not constitute a proper "branch", i.e. a fork in the commit history.) IMHO, tags should still be very much immutable. However, when working with remotes, you may get into a situation where the same tag name is independently set in different repos pointing at different commits. When these repos fetch from eachother, the tag name collision will be ignored, and each repo will keep their local version of the tag. Git will, AFAIK, not alert you to the tag name collision, and even after you identify the collision, it is not always easy to resolve it [1]. However, if we namespace remote tags (like we already do with remote branches), it is much easier to review which commits each remote has associated with a given tag name, and it's also much simpler to resolve which remote's tag you want to use in your own repo. (e.g. "git tag xyzzy refs/remotes/foo/tags/xyzzy"). > Second, I agree with Johan that the current semantics are confusing. I'm > basically the git guru here at work, so it falls to me to teach people > how git works and how to use it. I find that once people wrap their > minds around the concept of remote and local branches, they get tripped > up by the way tags work. > > IMHO it would be more intuitive if tags used the same local/remote > semantics as branches. I am in much the same situation at my $dayjob, and I can only agree. ...Johan [1]: Resolving tag collisions currently involves removing the tag from one repo and re-fetching from the other, or writing a custom refspec to rename the tag when fetching. -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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