[PATCH] tag: allow multiple tags to be added or removed

Matt Mackall mpm at selenic.com
Tue Mar 11 17:34:11 CDT 2008


On Tue, 2008-03-11 at 12:23 -0700, John Coomes wrote:
> Matt Mackall (mpm at selenic.com) wrote:
> > John Coomes wrote:
> > > Thomas Arendsen Hein (thomas at intevation.de) wrote:
> > >> * John Coomes <John.Coomes at sun.com> [20080223 09:33]:
> > >>> Patch to allow multiple tags to be added/removed in a single invocation
> > >>> of hg tag.  Basic example of the new usage is
> > >> ...
> > >> Generally we try to avoid singular vs. plural messages to make
> > >> parsing such messages (automatically and by brain) easier.
> > >>
> > >>> +    abort_nonempty([n for n in names if n in ['tip', '.', 'null']],
> > >>> +                   _('the name %s is reserved'),
> > >>> +                   _('the names %s are reserved'))
> > >> Maybe just loop over reserved names with singular message here.
> > > 
> > > Would this be acceptable?
> > > 
> > > 	$ hg tag -r 42 tip null
> > > 	tag: the name 'tip' is reserved
> > > 	tag: the name 'null' is reserved
> > > 	abort: reserved tag name
> > 
> > It would be simpler if it just aborted on the first problem.
> 
> Definitely simpler, and the odds of multiple errors are pretty low
> here, so I'll make the change.  I went down the path of listing all
> errors because I get frustrated by compilers and other tools that give
> up at the first error, only to make you rerun again to find the next
> one.
> 
> > > Or if there is a recommended format for such messages, let me know.
> > > 
> > >>> +    tag_word = (len(names) > 1 and _('tags')) or _('tag')
> > >> Some languages use singular for 21, 31, ... so this will get you (or
> > >> others) in translation hell :)
> > > 
> > > I'll use i18n.t.ngettext() for this as suggested by Martin.
> > 
> > No, don't. We intentionally ignore the whole pluralization issue, it's 
> > just not worth the complexity. For us or for parsers.
> 
> No problem.  Say we've run the commands "hg tag beta-1" and "hg tag
> beta-2 build-24".  What should the respective commit messages look
> like?
> 
> (a)	Added tag beta-1 for changeset abcdefabcdef
> 	Added tag beta-2, build-24 for changeset fedcbafedcba
> 
> (b)	Added tag beta-1 for changeset abcdefabcdef
> 	Added tag beta-2 and tag build-24 for changeset fedcbafedcba
> 
> (c)	Added tag(s) beta-1 for changeset abcdefabcdef
> 	Added tag(s) beta-2, build-24 for changeset fedcbafedcba

And there's also:

(d) Added tag beta-1..
    Added tag beta-2..
    Added tag build-24..

That is, just put two lines in the commit. The downside, of course, is
that you only get part of the picture with the short log message.

I'd go with (a), because it's obvious what happens with 3 tags:

 Added tag a, b, c...  (ie tags.join(", "))

while b might give you either

 Added tag a, b, and c...  (complicated, but standard English)

or

 Added tag a and b and c  (ie tags.join(" and "))

> (a) is closest to the existing message, if just slightly ambiguous;
> (b) is unambiguous, but a bit more verbose; (c) is a commonly-used but
> unattractive variant listed for completeness.  I like (a) or (b), w/a
> slight preference for (b).
> 
> -John
-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list