"Kristoffer Haugsbakk" <kristofferhaugsbakk@xxxxxxxxxxxx> writes:
> Hi, I get different results based on the order:
>
> git rev-list HERE..THERE --no-walk
>
> This (like you say) only outputs “there”.
>
> But this one outputs several:
>
> git rev-list --no-walk HERE..THERE
Thanks, Kristoffer, for looking at the report.
The subject line says "rev-list --no-walk RANGE", but that command
line works as documented. The real complaint in the report is about
"rev-list RANGE --no-walk". This thread is titled incorrectly.
In this particular case, because HERE..THERE implies "--walk" (and
that is how "git show A" and "git show A..B" behave the way users
are used to. "git show" itself behaves as if it has an implicit
"--no-walk" at the beginning, and later "--walk" overrides it), it
is understandable that
rev-list --no-walk HERE..THERE
walks (following the usual "last one wins" rule, allowing the later
implicit "--walk" to override "--no-walk"), while
rev-list HERE..THERE --no-walk
does not walk (again, following the usual "last one wins" rule,
the implicit "--walk" given by HERE..THERE gets overriden by an
explicit "--no-walk" that comes later).
But in general, the documentation assumes that the user follows the
usual command-line convention used throughout Git (see git help
cli---dashed options come before revs and paths). The command line
parser still accepts command line arguments in non-canonical order
(i.e. revs are given and then an option, in the problematic example
in this thread) without complaining, but this is done primarily to
cater to old timers, those who expect the commands to keep behaving
the way they happened to behave, which may or may not appear "sane"
to untrained eyes ;-).
Thanks.
