:) I would say it should also remove (in any way) local  tags, associated with
commit, being rolled back. Because it also confuses hgk and who knows how many
other scripts.

Hum.. I see how "00..00" will help with this - you can put local tag with same
name and "00...00" revision to overide global tag. But why do you need to keep
all this local history of tag changes? If I were using tags heavily I end up
with tooo bloated '.hgtags' and 'localtags'.

And it is strange that it is possible to remove global tag only by overriding it
first:

C:\Temp>hg tag test 

C:\Temp>hg tags 
tip                                1:81a828e146a2
test                               0:9b410491507b

C:\Temp>hg tag --remove -l -f test 
abort: tag 'test' is not a local tag

C:\Temp>hg tag -l -f test 

C:\Temp>hg tags 
tip                                1:81a828e146a2
test                               1:81a828e146a2

C:\Temp>hg tag --remove -l test 

C:\Temp>hg tags 
tip                                1:81a828e146a2

And then one more interesting thing

C:\Temp>hg tag test 

C:\Temp>hg tags 
tip                                2:325a1b6fbe83

Oops.. where is my tag? :)

I think you're overcomplicating idea of tags. I've shown one inconsistency
problem when playing with global and local tags, but I'm sure there're more.
Such things may lead to unwanted/unexpected behaviour of hg and its scripts,
causing bad user experience. That's my imho.

It allows you to locally 'remove' a global tag.

I think you've convinced me to kill the warning message.

Update. Doing 'hg tag --remove -l' does not help:

C:\Temp>hg tag -l "second"  

C:\Temp>hg tag --remove -l "second" 

C:\Temp>hg rollback  
rolling back last transaction

C:\Temp>hg log  
localtags, line 1: tag 'second' refers to unknown node

This is because tags are not realle removed from 'localtags' file, but rather
marked as deleted:

5d7cf0d8099c436e8170d84c3c83cc66c5c76ad0 second
0000000000000000000000000000000000000000 second

What is the reason for marking tags as removed instead of real remove?

Yeah, I read it well.
But I insist that this is a bug - any command performed on repository must end
up with correct state of repository. But rollback does not leave repo in correct
state in this case.

Again, I do not want to rollback 'hg tag -l' operation, leaving last commit in
place, I want all tags, related to commit being rolled back, removed.

Not a bug. You've mistaken 'rollback' for 'undo'.

Please read 'hg help rollback' starting with 'this command should be used with
care'. Local tags do not involve a transaction such as a commit, and thus are
not affected by rollback. Instead you just lost your last commit.

Seems like using mercurial makes you used to this bugtracker..
One more bug.

When you've set local tag on last revision and then rollback it, local tag is
not removed, causing error message:

  localtags, line 1: tag 'second' refers to unknown node

Way to reproduce:


C:\Temp>hg --version 
Mercurial Distributed SCM (version 1.0.1+20080525)

Copyright (C) 2005-2008 Matt Mackall <mpm@xxx> and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

C:\Temp>hg init 

C:\Temp>echo  1>1.txt 

C:\Temp>hg add 
adding 1.txt
adding cmd.cmd
adding log.log

C:\Temp>hg ci -m "first" 

C:\Temp>echo  1>2.txt 

C:\Temp>hg add 
adding 2.txt

C:\Temp>hg ci -m "second" 

C:\Temp>hg tag -l "second" 

C:\Temp>hg rollback 
rolling back last transaction

C:\Temp>hg log 
localtags, line 1: tag 'second' refers to unknown node
changeset:   0:9e23f71fc1d4
tag:         tip
user:        Alexander Chemeris <Alexander.Chemeris@xxx>
date:        Fri Jun 20 23:01:13 2008 +0400
summary:     first