Manually adding tags

[Scott Palmer]

On 2011-08-26, at 1:45 PM, Mads Kiilerich wrote:

> On 08/26/2011 03:41 PM, Scott Palmer wrote:
>> 
>> On 2011-08-26, at 8:40 AM, Isaac Jurado wrote:
>> 
>>> On Fri, Aug 26, 2011 at 1:26 PM, Scott Palmer<swpalmer at gmail.com>  wrote:
>>>> 
>>>>> If I understood correctly, you wan to tag a changeset you are about
>>>>> to commit, right?  If that is the case, you can forget about it
>>>>> because the .hgtags file needs the revision ID (the SHA) which you
>>>>> can't know until AFTER commit has been done.  So there is a
>>>>> bootstrapping problem.
>>>>> 
>>>>> Besides, the "hg tag" command is just that:
>>>>> 
>>>>> $ echo "version shaid">>.hgtags&&  hg commit
>>>> 
>>>> I think he just wants to include more in that same commit. He is still
>>>> tagging an older version.
>>> 
>>> Oh well, in that case what I wrote doesn't apply.
>> 
>> Now that I think about it, wouldn't it make sense to have something like a --no-commit option for hg tag ?
> 
> At first I thought we already had that option, but you are right. Some other commands that commits as a side effect has an option to disable it.
> 
>> That way we avoid people directly mucking about in the .hgtags file.  That could possible avoid some of the things that Greg was warning about earlier in this thread.
> 
> _Not_ having the --no-commit option is the ultimate way to avoid people mucking directly about in the .hgtags file if just they accept that and play by the rules ...
> 
> Mercurial tags happens to be implemented in such a way that it automatically makes some commits. That is an implementation detail that shows up in a few places, but I think the best advice is to just get over it and move on to something more important.

So be it.  I can say though that I was at first a little startled that hg tag did a commit… it felt unnatural.  I expected hg commit to be the exclusive means of creating a new changeset.  It isn't, and I can get over it :-)

Scott