Re: git rev-list --no-walk RANGE not working as documented

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 2, 2024, 19:18 UTC
Message-ID: <xmqqzfnml3es.fsf@gitster.g>
In-Reply-To: <7fddacf9-55f6-4520-a288-279d3784badb@app.fastmail.com>

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

Show 9 quoted lines

> 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.