Junio C Hamano wrote:
Pierre Habouzit <madcoder@xxxxxxxxxx> writes:
Yep, let's do it then. Note that's the reason why I felt we need a
manual page about this, because we should give some guidelines of what
is safe for scripting.
There are some fallouts from the series, though. I've fixed up git-tag
but I strongly suspect all of parseopt users now need careful auditing.
If we cannot be confident with the parseoptified commands within
reasonably short timeframe by -rc1, we may end up having to revert the
parseopt changes from them, which I'd rather avoid, but if you look at
the git-tag change (especially for -l) you would understand it. The
"must stick" restriction feels Ok on paper but in practice it looks
rather draconian and very user unfriendly.
Usually, optional arguments warrant adding a second parameter. This can
often even improve usability, as it's never unclear or ambiguous what's
happening. For the 'git tag -l' case, I'd use something like
'git tag -l --match="regex"' or some such, or perhaps make "-l" its own
subcommand ("list") with a built-in alias of -l. That means "-l" has to
be the first argument after "git tag" on the command-line, but I suspect
it doesn't make much sense to use it along with other options anyway, so
perhaps that's not much of an issue.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
