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

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

[Peter Colberg]

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:

% 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
2026

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

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

[Kristofer Karlsson]

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