Re: [PATCH v4 00/12] builtin/rerere: convert to use subcommands

[Junio C Hamano <gitster@pobox.com>]

Does the new syntax introduce a subtle UI regression that does not
allow certain options before subcommands?  We used to take "git
rerere --skip-locked gc", but now it has to be spelled as "git
rerere gc --skip-locked", it seems.

I do not particularly care about the '--skip-locked' option itself,
and I personally prefer to see options after non-options as a
general CLI principle, but it seems that it is now required to give
the option after the "gc" subcommand.

I do not know how often people run "git rerere" with these
subcommands themselves.  This subtle change in the CLI may go
unnoticed in a smaller project, but because we probably have more
than a few thousand users, I am afraid that somebody will notice.

In the transcript below, "rungit TRACK" is my short-hand to run
version of "git" from that integration branch.

$ rungit master rerere --skip-locked gc
$ rungit next rerere --skip-locked gc
$ rungit seen rerere --skip-locked gc
error: unknown option `skip-locked'
usage: git rerere [--[no-]rerere-autoupdate]

    --[no-]rerere-autoupdate
                          register clean resolutions in index
$ rungit seen rerere gc --skip-locked