Jakub Narebski wrote: > Matt Mackall wrote: >> On Fri, Feb 02, 2007 at 06:18:10PM +0100, Jakub Narebski wrote: > >>> Revision-controlled (in-tree) tags are inane idea. Tags are non-moving >>> (and sometimes annotated) pointers to given point in history. They should >>> not depend on which branch you are, or what version you have checked out. >> >> And.. they don't! > > If that means that you always use the version of .hgtags from the tip > (branches are tips of history; they can have different .hgtags), > this is also broken; this means for example that you cannot compare > current version when on development head (branch) with tag on different > branch, those two branches have the same .hgtags file. I meant to write: ..._unless_ those two branches have the same .hgtags file. > "They should not depend on which branch you are"... and they can. For example you are on branch 'master', you tag current release e.g. v1.3.4, then you checkout branch 'devel'... and you don't have v1.3.4 tag available unless you merge in .hgtags from 'master'. At least from what I understand of Mercurial tags behaviour. Having to create a commit to remember tag which can be published... I'm not sure if it is a good idea either. Junio creates "GIT 1.4.4.3" commits, ant those are tagges, so perhaps it is not so bad idea either. You encourage to hand-edit .hgtags, but the edited version might not be the one that is used (for example when starting a branch). -- Jakub Narebski Poland - 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