threads / discuss / 63005

'git rev-list' commit ordering issue

Subject: 'git rev-list' commit ordering issue

## tl;dr

5 messages between Feb 26, 2025 and Feb 28, 2025.

replies: 4people: 3as markdown or json

Clement Moyroud· Feb 26, 2025, 01:43 UTC · lore
Hello,

I've come across an issue with `git rev-list --no-walk=sorted` commit ordering when two commits have the exact same commit date. In that case, `git rev-list` will leave the two commits in the original order, preventing automated cherry-picking.

To reproduce starting from the attached repo archive created with `git bugreport`: git rev-list --reverse HEAD | git rev-list --no-walk=sorted --stdin

You'll see that the order of the two middle commits is incorrect and does not match the order returned by `git rev-list HEAD`

Since both commits have the same commit date, `git rev-list` should use another criterion to do the sorting - namely, use the parent/child topology.

If there are better ways to sort such a list, let me know. This is a much simplified test case. In our real-world application, we start from a subset of commits that we want to cherry-pick from a branch, for the purpose of creating a customer-specific patch build. For the automated cherry-pick to work, we need to have these commits sorted in topological order. I do not see an option to `git rev-list` that only sorts the commits in stdin topologically - the `--no-walk` option only does date-based sorting.

Below is the system info gathered by `git bugreport`.
Take care,
Clement
[System Info]
git version:
git version 2.48.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
libcurl: 7.87.0
OpenSSL: OpenSSL 1.0.1e-fips 11 Feb 2013
zlib: 1.2.3
uname: Linux 4.18.0-553.33.1.el8_10.x86_64 #1 SMP Thu Dec 19 14:28:01
UTC 2024 x86_64
compiler info: gnuc: 6.2
libc info: glibc: 2.28
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
D. Ben Knoble· Feb 26, 2025, 18:57 UTC · re: Clement Moyroud · lore

Re: 'git rev-list' commit ordering issue

On Tue, Feb 25, 2025 at 8:44 PM Clement Moyroud <clement.moyroud@gmail.com> wrote:

Show 28 quoted lines
>
> Hello,
>
> I've come across an issue with `git rev-list --no-walk=sorted` commit
> ordering when
> two commits have the exact same commit date. In that case, `git rev-list` will
> leave the two commits in the original order, preventing automated
> cherry-picking.
>
> To reproduce starting from the attached repo archive created with `git
> bugreport`:
> git rev-list --reverse HEAD | git rev-list --no-walk=sorted --stdin
>
> You'll see that the order of the two middle commits is incorrect and
> does not match
> the order returned by `git rev-list HEAD`
>
> Since both commits have the same commit date, `git rev-list` should use another
> criterion to do the sorting - namely, use the parent/child topology.
>
> If there are better ways to sort such a list, let me know. This is a much
> simplified test case. In our real-world application, we start from a subset
> of commits that we want to cherry-pick from a branch, for the purpose
> of creating
> a customer-specific patch build. For the automated cherry-pick to work, we need
> to have these commits sorted in topological order. I do not see an option to
> `git rev-list` that only sorts the commits in stdin topologically - the
> `--no-walk` option only does date-based sorting.
Is `--topo-order` of no help here?
Show 27 quoted lines
>
> Below is the system info gathered by `git bugreport`.
>
> Take care,
>
> Clement
>
>
> [System Info]
> git version:
> git version 2.48.1
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> libcurl: 7.87.0
> OpenSSL: OpenSSL 1.0.1e-fips 11 Feb 2013
> zlib: 1.2.3
> uname: Linux 4.18.0-553.33.1.el8_10.x86_64 #1 SMP Thu Dec 19 14:28:01
> UTC 2024 x86_64
> compiler info: gnuc: 6.2
> libc info: glibc: 2.28
> $SHELL (typically, interactive shell): /bin/zsh
>
>
> [Enabled Hooks]
-- 
D. Ben Knoble
Clement Moyroud· Feb 26, 2025, 22:30 UTC · re: D. Ben Knoble · lore

Re: 'git rev-list' commit ordering issue

On Wed, Feb 26, 2025 at 10:58 AM D. Ben Knoble <ben.knoble@gmail.com> wrote:
Show 33 quoted lines
>
> On Tue, Feb 25, 2025 at 8:44 PM Clement Moyroud
> <clement.moyroud@gmail.com> wrote:
> >
> > Hello,
> >
> > I've come across an issue with `git rev-list --no-walk=sorted` commit
> > ordering when
> > two commits have the exact same commit date. In that case, `git rev-list` will
> > leave the two commits in the original order, preventing automated
> > cherry-picking.
> >
> > To reproduce starting from the attached repo archive created with `git
> > bugreport`:
> > git rev-list --reverse HEAD | git rev-list --no-walk=sorted --stdin
> >
> > You'll see that the order of the two middle commits is incorrect and
> > does not match
> > the order returned by `git rev-list HEAD`
> >
> > Since both commits have the same commit date, `git rev-list` should use another
> > criterion to do the sorting - namely, use the parent/child topology.
> >
> > If there are better ways to sort such a list, let me know. This is a much
> > simplified test case. In our real-world application, we start from a subset
> > of commits that we want to cherry-pick from a branch, for the purpose
> > of creating
> > a customer-specific patch build. For the automated cherry-pick to work, we need
> > to have these commits sorted in topological order. I do not see an option to
> > `git rev-list` that only sorts the commits in stdin topologically - the
> > `--no-walk` option only does date-based sorting.
>
> Is `--topo-order` of no help here?

Unfortunately no, because it'll look at the ancestors. I get more commits (400k+ extra commits in my real world case) than I have on stdin: $ git log -1 --pretty=%H 2025.2 | git rev-list --stdin --topo-order --count 417776

-- Clement

Show 33 quoted lines
>
> >
> > Below is the system info gathered by `git bugreport`.
> >
> > Take care,
> >
> > Clement
> >
> >
> > [System Info]
> > git version:
> > git version 2.48.1
> > cpu: x86_64
> > no commit associated with this build
> > sizeof-long: 8
> > sizeof-size_t: 8
> > shell-path: /bin/sh
> > libcurl: 7.87.0
> > OpenSSL: OpenSSL 1.0.1e-fips 11 Feb 2013
> > zlib: 1.2.3
> > uname: Linux 4.18.0-553.33.1.el8_10.x86_64 #1 SMP Thu Dec 19 14:28:01
> > UTC 2024 x86_64
> > compiler info: gnuc: 6.2
> > libc info: glibc: 2.28
> > $SHELL (typically, interactive shell): /bin/zsh
> >
> >
> > [Enabled Hooks]
>
>
>
> --
> D. Ben Knoble
Phillip Wood· Feb 28, 2025, 10:59 UTC · re: Clement Moyroud · lore

Re: 'git rev-list' commit ordering issue

Hi Clement
On 26/02/2025 22:30, Clement Moyroud wrote:
> On Wed, Feb 26, 2025 at 10:58 AM D. Ben Knoble <ben.knoble@gmail.com> wrote:
 >
Show 7 quoted lines
>> Is `--topo-order` of no help here?
> 
> Unfortunately no, because it'll look at the ancestors. I get more
> commits (400k+ extra
> commits in my real world case) than I have on stdin:
> $ git log -1 --pretty=%H 2025.2 | git rev-list --stdin --topo-order --count
> 417776
This seems to have lost "--no-walk".
     ... | git rev-list --stdin --topo-order --no-walk
should list only the commits passed on stdin in topographic order I think.
Best Wishes
Phillip
Show 37 quoted lines
> --
> Clement
> 
>>
>>>
>>> Below is the system info gathered by `git bugreport`.
>>>
>>> Take care,
>>>
>>> Clement
>>>
>>>
>>> [System Info]
>>> git version:
>>> git version 2.48.1
>>> cpu: x86_64
>>> no commit associated with this build
>>> sizeof-long: 8
>>> sizeof-size_t: 8
>>> shell-path: /bin/sh
>>> libcurl: 7.87.0
>>> OpenSSL: OpenSSL 1.0.1e-fips 11 Feb 2013
>>> zlib: 1.2.3
>>> uname: Linux 4.18.0-553.33.1.el8_10.x86_64 #1 SMP Thu Dec 19 14:28:01
>>> UTC 2024 x86_64
>>> compiler info: gnuc: 6.2
>>> libc info: glibc: 2.28
>>> $SHELL (typically, interactive shell): /bin/zsh
>>>
>>>
>>> [Enabled Hooks]
>>
>>
>>
>> --
>> D. Ben Knoble
>
Clement Moyroud· Feb 28, 2025, 16:05 UTC · re: Phillip Wood · lore

Re: 'git rev-list' commit ordering issue

On Fri, Feb 28, 2025 at 2:59 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
Show 24 quoted lines
>
> Hi Clement
>
> On 26/02/2025 22:30, Clement Moyroud wrote:
> > On Wed, Feb 26, 2025 at 10:58 AM D. Ben Knoble <ben.knoble@gmail.com> wrote:
>  >
> >> Is `--topo-order` of no help here?
> >
> > Unfortunately no, because it'll look at the ancestors. I get more
> > commits (400k+ extra
> > commits in my real world case) than I have on stdin:
> > $ git log -1 --pretty=%H 2025.2 | git rev-list --stdin --topo-order --count
> > 417776
>
> This seems to have lost "--no-walk".
>
>      ... | git rev-list --stdin --topo-order --no-walk
>
> should list only the commits passed on stdin in topographic order I think.
>
> Best Wishes
>
> Phillip
>
Hi Philip,
I wish that were the case :) Per the docs:
| If the argument unsorted is given, the commits are shown in the order they
| were given on the command line. Otherwise (if sorted or no argument was
| given), the commits are shown in reverse chronological order by commit time.

As soon as you specify --no-walk, topological ordering is disabled. I _think_ it's because it will instruct `rev-list` not to look at the ancestors. It looks like a new in-between option is needed, where topological ordering is used when the dates match.

Cheers,
Clement
Show 38 quoted lines
> > --
> > Clement
> >
> >>
> >>>
> >>> Below is the system info gathered by `git bugreport`.
> >>>
> >>> Take care,
> >>>
> >>> Clement
> >>>
> >>>
> >>> [System Info]
> >>> git version:
> >>> git version 2.48.1
> >>> cpu: x86_64
> >>> no commit associated with this build
> >>> sizeof-long: 8
> >>> sizeof-size_t: 8
> >>> shell-path: /bin/sh
> >>> libcurl: 7.87.0
> >>> OpenSSL: OpenSSL 1.0.1e-fips 11 Feb 2013
> >>> zlib: 1.2.3
> >>> uname: Linux 4.18.0-553.33.1.el8_10.x86_64 #1 SMP Thu Dec 19 14:28:01
> >>> UTC 2024 x86_64
> >>> compiler info: gnuc: 6.2
> >>> libc info: glibc: 2.28
> >>> $SHELL (typically, interactive shell): /bin/zsh
> >>>
> >>>
> >>> [Enabled Hooks]
> >>
> >>
> >>
> >> --
> >> D. Ben Knoble
> >
>

← back to recent threads