rev_walk git sorting not being obeyed

[kallisti5]

Current behavior 😯

Modifying the walk order seems to no have no impact on the ordering of results.

gix = { version = "0.73", default-features = false, features = [
  "tracing",
  "parallel",
  "blob-diff",
  "revision",
] }

Expected behavior 🤔

Expect the ability to modify the ordering of commits being walked (oldest to newest, newest to oldest)

Git behavior

$ git log | grep commit | head -10
commit cc9b130baf883388b435f6ecc5a66fc2a5bbc15f
commit c29e363c90e74fc4f1946f611dd51faae665a93e
commit 49d57bc76209d98ce77a76edf5b2cdb7b7621625
commit aa089d42aba17a1ad0e740ea3a18651676c94295
commit cd32523ff348a8075542ed76a40dc6068ba1bdfc
commit f39a8fb99d6addff22736e7f17bb5ec2886c7dc3
commit 066e2ddaed3a979be8495c933bcc0b8d0d503496
commit 967d8befe574eea1a5d24834f8168a07f2822307
commit 528742a734ee2e31ae53d888d6e717238986cb6b
commit 32073fe7d118c73bd4a681f711bb885c4c95a431

Steps to reproduce 🕹

Specify "OldestFirst"...

    let mut hasher = Xxh3::new();
    let tree_len = commit_tree.len()?;
    let mut seen = false;
    let mut i = 0;

    let sorting = Sorting::ByCommitTime(CommitTimeOrder::OldestFirst);
    let revwalk_iter = git_repository.rev_walk([commit.id()]).sorting(sorting).all()?;
    for revwalk in revwalk_iter {
        for revs in &revwalk.into_iter().chunks(250) {
            if ((i + 1) % 5_000) == 0 {
                info!("{}: {} commits ingested", reference.name().shorten(), i + 1);
            }
            let mut batch = WriteBatch::default();
            for rev in revs {
                if let (false, Some(latest_indexed)) = (seen, &latest_indexed) {
                    if rev.id.as_bytes() == latest_indexed.get().hash.as_slice() {
                        seen = true;
                    }
                    continue;
                }

                seen = true;
                let commit = rev.object()?;
                let oid = commit.id;
                let commit = commit.decode()?;
                let author = commit.author();
                let committer = commit.committer();
                info!("Commit: {}", oid);

2025-11-25T20:06:05.798860Z  INFO index_update:update_repository_reflog{scan_path="/home/kallisti5/Code/greaseweazle"}:branch_index_update{relative_path=".git" force_reindex=false submodules={}}: gitore::database::indexer: master: Refreshing indexes
2025-11-25T20:06:05.798913Z  INFO index_update:update_repository_reflog{scan_path="/home/kallisti5/Code/greaseweazle"}:branch_index_update{relative_path=".git" force_reindex=false submodules={}}: gitore::database::indexer: Commit: cc9b130baf883388b435f6ecc5a66fc2a5bbc15f
2025-11-25T20:06:05.799158Z  INFO index_update:update_repository_reflog{scan_path="/home/kallisti5/Code/greaseweazle"}:branch_index_update{relative_path=".git" force_reindex=false submodules={}}: gitore::database::indexer: Commit: c29e363c90e74fc4f1946f611dd51faae665a93e
2025-11-25T20:06:05.799198Z  INFO index_update:update_repository_reflog{scan_path="/home/kallisti5/Code/greaseweazle"}:branch_index_update{relative_path=".git" force_reindex=false submodules={}}: gitore::database::indexer: Commit: 49d57bc76209d98ce77a76edf5b2cdb7b7621625

Changing it to "Newest First"...

diff --git a/src/database/indexer.rs b/src/database/indexer.rs
index fcd2e31..4c2601b 100644
--- a/src/database/indexer.rs
+++ b/src/database/indexer.rs
@@ -264,7 +264,7 @@ fn branch_index_update(
     let mut seen = false;
     let mut i = 0;

-    let sorting = Sorting::ByCommitTime(CommitTimeOrder::OldestFirst);
+    let sorting = Sorting::ByCommitTime(CommitTimeOrder::NewestFirst);
     let revwalk_iter = git_repository.rev_walk([commit.id()]).sorting(sorting).all()?;
     for revwalk in revwalk_iter {
         for revs in &revwalk.into_iter().chunks(250) {

2025-11-25T20:08:15.966311Z  INFO index_update:update_repository_reflog{scan_path="/home/kallisti5/Code/greaseweazle"}:branch_index_update{relative_path=".git" force_reindex=false submodules={}}: gitore::database::indexer: master: Refreshing indexes
2025-11-25T20:08:15.966350Z  INFO index_update:update_repository_reflog{scan_path="/home/kallisti5/Code/greaseweazle"}:branch_index_update{relative_path=".git" force_reindex=false submodules={}}: gitore::database::indexer: Commit: cc9b130baf883388b435f6ecc5a66fc2a5bbc15f
2025-11-25T20:08:15.966596Z  INFO index_update:update_repository_reflog{scan_path="/home/kallisti5/Code/greaseweazle"}:branch_index_update{relative_path=".git" force_reindex=false submodules={}}: gitore::database::indexer: Commit: c29e363c90e74fc4f1946f611dd51faae665a93e
2025-11-25T20:08:15.966637Z  INFO index_update:update_repository_reflog{scan_path="/home/kallisti5/Code/greaseweazle"}:branch_index_update{relative_path=".git" force_reindex=false submodules={}}: gitore::database::indexer: Commit: 49d57bc76209d98ce77a76edf5b2cdb7b7621625

[kallisti5]

As an addition, rev() does nothing to the iter as an alternative.
I'd prefer "BreadthLast" to be honest 😅

[Byron]

Thanks for reporting!

I think this issue should be mostly about the misconception that the rev-walk implementation has anything to do with git log, which unfortunately isn't the case.

The sorting is only relevant when the next commit in the traversal is queued. This means that in a linear history, it makes no difference. In a branched history it helps to investigate newer commits and their dependencies before old ones, which also only matters if old portions are merged into more recent ones.

As an addition, rev() does nothing to the iter as an alternative.

It's interesting that .rev() is even offered - the returned iterator isn't double-sided, so .rev() isn't possible. Probably it comes from itertools.

[kallisti5]

Ah! ok. Thank you for this explanation! So essentially, the only way to reverse commit ordering is in memory with a Vec?

    //let revwalk_iter = git_repository.rev_walk([commit.id()]).all()?.collect::<Vec<_>>().into_iter().rev(); // correct dataset
    let revwalk_iter = git_repository.rev_walk([commit.id()]).all()?; // reversed dataset

The biggest pain point is dealing with the memory consumption of "BIG" git repos with the Vec collection.

[Byron]

The biggest pain point is dealing with the memory consumption of "BIG" git repos with the Vec collection.

Yes, I understand. Yet, there is nothing one can do about it.
git2 for instance offers a reversal, but it just does the Vec-collection under the hood for you.

[Byron]

So I am thinking this issue can be closed as it didn't demonstrate a bug that could be fixed.
If that changes, please feel free to reopen or post a comment here, or to create a new issue.
Thank you.