Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> Which is what I was mainly pointing out upthread, that your summary of
> options before other types of args omitted that many utilities support
> the reverse. Or perhaps you were only describing an asthetic choice
> (which I don't think is worth debating). I'm just talking about what the
> ground truth is.
The ground truth is that it is unlikely that we can fix some of our
commands so that they stop taking options that are given after args,
because of inertia. But we can teach users especially the new ones
to always use the canonical order to sidestep the whole "some
subcommands imitate misguided GNUism to make it ambiguous, some
don't" problem.
> What do you think about something like this to clear this up?:
As we should aspire to fix the misguided "options can come still
after we saw args" eventually (don't talk back on this point to
waste any more of my time on a release day), I do not think it is a
good idea to say "reverse is often not true" and stopping there.
It will mislead people to think these "not true" commands should
somehow be updated to the GNUism in the future. It's the other way
around.
> + * Options are (almost) universally accpted before other types of
> + arguments, e.g. `git cat-file -t HEAD` or `git push --dry-run
> + origin`, but in the case of those commands a GNU-style `git
> + cat-file HEAD -t` and `git push origin --dry-run` would work just
> + as well. The reverse is often not true, many commands do not accept
> + options after non-option arguments.
* A subcommand may take dashed options (which may take their own
arguments, e.g. "--max-parents 2") and arguments. You SHOULD
give dashed options first and then arguments. Some commands may
accept dashed options after you have already gave non-option
arguments (which may make the command ambiguous), but you should
not rely on it (because eventually we may find a way to fix
these ambiguity by enforcing the "options then args" rule).
