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

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

[squeaky]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

git rev-list HERE..THERE --no-walk

What did you expect to happen? (Expected behavior)

Show the commits between HERE and THERE. 

What happened instead? (Actual behavior)

Only THERE is shown.

What's different between what you expected and what actually happened?

The documentation for --no-walk says, "This has no effect if a range is specified."
Since HERE..THERE is a range, --no-walk should have no effect. This isn't working as documented.

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.39.2.501.gd9d677b2d8
cpu: x86_64
built from commit: d9d677b2d8cc5f70499db04e633ba7a400f64cbf
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.1.6-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jan 14 16:55:06 UTC 2023 x86_64
compiler info: gnuc: 12.2
libc info: glibc: 2.36
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]
[root@xps git] 

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

[Kristoffer Haugsbakk]

On Tue, Feb 21, 2023, at 00:54, squeaky wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> git rev-list HERE..THERE --no-walk
>
> What did you expect to happen? (Expected behavior)
>
> Show the commits between HERE and THERE.
>
> What happened instead? (Actual behavior)
>
> Only THERE is shown.
>
> What's different between what you expected and what actually happened?
>
> The documentation for --no-walk says, "This has no effect if a range is
> specified."
> Since HERE..THERE is a range, --no-walk should have no effect. This
> isn't working as documented.
>
> Anything else you want to add:
>
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
>
>
> [System Info]
> git version:
> git version 2.39.2.501.gd9d677b2d8
> cpu: x86_64
> built from commit: d9d677b2d8cc5f70499db04e633ba7a400f64cbf
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Linux 6.1.6-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jan 14
> 16:55:06 UTC 2023 x86_64
> compiler info: gnuc: 12.2
> libc info: glibc: 2.36
> $SHELL (typically, interactive shell): /bin/bash
>
>
> [Enabled Hooks]
> [root@xps git]

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

-- 
Kristoffer Haugsbakk

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

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> 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.