Git 2.55.0 breaks revision path filtering with --no-walk

Peter ColbergJul 15, 2026, 18:48 UTC on lore

Hi,

Since commit dd4bc01c0a8f ("revision: use priority queue for non-limited streaming walks") in Git 2.55.0, git rev-list --no-walk no longer considers optional <path>... arguments.

https://lore.kernel.org/git/pull.2127.git.1779897003.gitgitgadget@gmail.com/

The following example lists all commits between two Linux kernel releases that modify paths within a given directory and further modified paths outside of that directory, too.

With Git 2.54.0, the second rev-list correctly filters by paths:

% git rev-list --topo-order v7.0..v7.1 -- drivers/gpu/drm/ | wc -l 2026 % git rev-list --topo-order v7.0..v7.1 -- drivers/gpu/drm/ | git rev-list --stdin --no-walk=unsorted -- ':!drivers/gpu/drm/' | wc -l 146

With Git 2.55.0, the second rev-list passes through all commits:

Reverting commit dd4bc01c0a8f ("revision: use priority queue for non-limited streaming walks") on top of Git 2.55.0 restores the previous behaviour. Specifically, the following hunk that no longer invokes process_parents() in the no_walk case causes the regression.

@@ -4390,12 +4394,13 @@ static struct commit *get_revision_1(struct rev_info *revs)
 			break;
 		case REV_WALK_STREAMING:
 			if (process_parents(revs, commit,
-					    &revs->commits, NULL) < 0) {
+					    &revs->commit_queue) < 0) {
 				if (!revs->ignore_missing_links)
 					die("Failed to traverse parents of commit %s",
 					    oid_to_hex(&commit->object.oid));
 			}
 			break;
+		case REV_WALK_NO_WALK:
 		case REV_WALK_LIMITED:
 			break;
 		}

Is the behaviour in Git 2.55.0 intentional, i.e., was --no-walk never
intended to support path filtering, or is this indeed a regression?

Thanks,
Peter

Kristofer KarlssonJul 15, 2026, 21:09 UTC in reply to Peter Colberg on lore

Re: Git 2.55.0 breaks revision path filtering with --no-walk

On Wed, 15 Jul 2026 at 20:48, Peter Colberg <pcolberg@redhat.com> wrote:

>
> Is the behaviour in Git 2.55.0 intentional, i.e., was --no-walk never
> intended to support path filtering, or is this indeed a regression?

Ouch, this definitely seems like a regression and it can be reproduced with a very simple scenario:

  git init repo && cd repo
  echo a >file-a && git add file-a && git commit -m "add file-a"
  echo b >file-b && git add file-b && git commit -m "add file-b"
  git rev-list --no-walk HEAD -- file-a

This should produce no output since HEAD only touches file-b, but with 2.55.0 it incorrectly outputs the commit.

I think you correctly identified the problematic change too, my refactoring indeed has a bug where process_parents() is skipped.

I think I can fix it, and also add test cases for this, but I am not sure what the immediate appropriate action is -- revert the entire patch or apply a bugfix? I think I can also try to check if there are other affected code paths that need additional test cases.

For what it's worth, I suspect the bugfix would look something like this, but I have not fully verified it yet.

in revision.c:
     case REV_WALK_NO_WALK:
    +        try_to_simplify_commit(revs, commit);
    +        break;
     case REV_WALK_LIMITED:

Thanks for the report, I will try to contribute a fix if possible, Kristofer