# 'git rev-list' commit ordering issue 5 messages from 2025-02-26 to 2025-02-28. Participants: Clement Moyroud, D. Ben Knoble, Phillip Wood. Thread: https://gitlist.dev/t/63005 ## Clement Moyroud, 2025-02-26 01:43 Subject: 'git rev-list' commit ordering issue Message-ID: URL: https://gitlist.dev/e/CABXAcUxHp3LnyqR%3DNM0coh6wG-1uy4GB3FdeZEg8mPHu-vt0bQ%40mail.gmail.com ``` 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, 2025-02-26 18:57 Subject: Re: 'git rev-list' commit ordering issue Message-ID: URL: https://gitlist.dev/e/CALnO6CA2j60gpPhUjxOY6_q5WdU7MHoL1GLDN_AVwWVNx_JddQ%40mail.gmail.com In-Reply-To: ``` On Tue, Feb 25, 2025 at 8:44 PM Clement Moyroud 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? > > 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, 2025-02-26 22:30 Subject: Re: 'git rev-list' commit ordering issue Message-ID: URL: https://gitlist.dev/e/CABXAcUwHd2Rr8iOZ7F2k5DGiBNH87pwG3oyRWLrP40%3DMgD91-w%40mail.gmail.com In-Reply-To: ``` On Wed, Feb 26, 2025 at 10:58 AM D. Ben Knoble wrote: > > On Tue, Feb 25, 2025 at 8:44 PM Clement Moyroud > 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 > > > > > 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, 2025-02-28 10:59 Subject: Re: 'git rev-list' commit ordering issue Message-ID: URL: https://gitlist.dev/e/d7b1416d-d201-400e-a0eb-b9e526f740ab%40gmail.com In-Reply-To: ``` Hi Clement On 26/02/2025 22:30, Clement Moyroud wrote: > On Wed, Feb 26, 2025 at 10:58 AM D. Ben Knoble 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 > -- > 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, 2025-02-28 16:05 Subject: Re: 'git rev-list' commit ordering issue Message-ID: URL: https://gitlist.dev/e/CABXAcUyWu3zi_iXrSoc1ymZCYtE5u4%2BJybJp2TiCCJA18T-4CQ%40mail.gmail.com In-Reply-To: ``` On Fri, Feb 28, 2025 at 2:59 AM Phillip Wood wrote: > > Hi Clement > > On 26/02/2025 22:30, Clement Moyroud wrote: > > On Wed, Feb 26, 2025 at 10:58 AM D. Ben Knoble 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 > > -- > > 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 > > > ```