On 2007-02-02 11:01, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >On Fri, 2 Feb 2007, Giorgos Keramidas wrote: >> Sometimes, 'sliding a tag' is a real-world need. Losing the >> information of who did the tag sliding and when, is not good. > > In practice, this is not much of an issue. Sure it is. Maybe not in the context of all projects or all teams, but properly versioning tag names and knowing who installed the tag, and when is quite often an issue with unversioned tags in some of the teams I have worked with. > First off, CVS tag usage is insane, but it's insane for *other* > reasons (ie people use tags differently in CVS, but they do it not > because they want to use tags that way, but because CVS makes it > impossible to do anything saner). > > So pointing to CVS tag usage as an argument is pointless. You might as > well say that you shouldn't save the merge information, because CVS > doesn't do it, and manual tags are a good way to do it. > > Secondly, the problems with tags having "history" is that you can't > really resolve them anyway. You have to pick one. You can't "merge" > them. Ok, maybe CVS was not so good as an example of why versioned tags *are* useful, but my comment came from the experience I have with the tagging of FreeBSD release builds. The -STABLE branch os FreeBSD may be tagged with RELENG_X_Y_Z_RELEASE at a particular point in time. If we find that some important bug fix has to go in, the fix is committed, and the tag can 'slide' forward for only a particular file or set of files. When tags are versioned, this operation is properly versioned too. It's apparent from browsing the global tag history that the specific tag *was* moved forward; it's obvious where it was pointing before the 'slide' operation; it's obvious which files the 'slide' affected, etc. Having the tags operations as an integral part of the visible history of all public repositories is not necessarily useful for 100% of the people who may skim through the logs, but I'm not sure why you suggest that it's difficult to "merge" tags. Since tags point to a very specific changeset hash, the hash serves as a unique, unconflicting identifier of the tag's location in history. When a "pull" operation happens, there are no conflicts unless there is a naming conflict between the "remote" and "local" repository. It's not impossible or even difficult to "merge" the two tag sets. > In other words, tags are atomic *events*, not history. And I certainly > agree that you shouldn't lose the events (unless you want to, of course). Tags are a little of two different things: (1) They are 'events' in the sense that someone has placed them to a tree, and this operation is a very real, very natural event, and *this* event should be versioned. (2) They are 'pointers' to a particular changeset id. The particular changeset hash to which they point, when the user looks at a specific revision of the history tree, is immuttable from the point of view of someone looking at this specific revision. It may *change* as the viewer moves back and forth into the history tree though. The pointer-nature of tags doesn't need to be versioned when one looks at one particular changeset, but the event-nature of their placement into the tree *can* be versioned and IMHO it *should* be versioned. Otherwise, there is no good way to provide accountability for these events, and some part of the repository 'history' is lost. > I also do agree that you can absolutely have something that is > basically a "tag that moves, and that you want to tie back to the > previous state of the tag". In git, we just happen to call those > things "branches". You're confusing a single, one-time movement of a tag (to point to a place *after* a bugfix, for instance), with the creation of a new, entirely separate, full branch. One of them is ok in some cases; the other is probably necessary in others. I can understand why they don't _both_ seem useful for all possible cases, but I don't see why we should limit ourselves to only one of the two options. - Giorgos - 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