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. 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. 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). 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 *could* technically put one of those things into the tag-namespace if you want to, although it would largely be considered insane by most git users (and you could see it historically: each "tag" would be a merge that points to its previous incarnation and to the point in time that got tagged). More commonly, you'd just use a "real tag", which includes the tagger information and a message about why something got tagged, plus possibly a PGP signature. That way, you can see (and save) all the individual events. Linus - 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