b4: prep --edit-cover emits strange message about "Already Ran"

DISCUSSION Dave Marquardt 2 participants 4 messages Mar 20

Share & tools

Dave Marquardt

author

2026-03-20 14:41 UTC #0 lore raw

I found the message here a little confusing, and had to go code spelunking to figure out what it might mean and how I should answer the Y/N question.

    $ b4 prep --edit-cover
    Waiting for Emacs...
    Invoking git-filter-repo to update the cover letter.
    The previous run is older than a day (/home/davemarq/linux/linux/.git/worktrees/ibmvfc-fpin-bis/filter-repo/already_ran already exists).
    See "Already Ran" section in the manual for more information.
    Treat this run as a continuation of filtering in the previous run (Y/N)? n
    New history written in 612.22 seconds...
    Completely finished after 612.53 seconds.
    Cover letter updated.

I first searched the b4 manual, and found nothing about "Already Ran". Eventually, on reading the b4 code in ez.py, I found this was from the git-filter-repo package and I should check its manual. I found the code. There's no way to opt out of this check and message.

Would you be interested in updating the b4 manual with a note about this? I eventually figured out I should answer with N. Perhaps an update to the --edit-cover text in "Prep command flags" in the manual? I'll provide it if you're interested.

-Dave

Matthieu Baerts

2026-03-20 14:52 UTC #1 lore raw

Hi Dave,

Quoted 14 lines · Dave Marquardt

I found the message here a little confusing, and had to go code spelunking to figure out what it might mean and how I should answer the Y/N question.

    $ b4 prep --edit-cover
    Waiting for Emacs...
    Invoking git-filter-repo to update the cover letter.
    The previous run is older than a day (/home/davemarq/linux/linux/.git/worktrees/ibmvfc-fpin-bis/filter-repo/already_ran already exists).
    See "Already Ran" section in the manual for more information.
    Treat this run as a continuation of filtering in the previous run (Y/N)? n
    New history written in 612.22 seconds...
    Completely finished after 612.53 seconds.
    Cover letter updated.

Quoted 4 lines

I first searched the b4 manual, and found nothing about "Already Ran". Eventually, on reading the b4 code in ez.py, I found this was from the git-filter-repo package and I should check its manual. I found the code. There's no way to opt out of this check and message.

Yes, there is: simply by removing the file. That's what b4 is doing for a while, and it has been backported in the last stable version (0.14.3):

https://git.kernel.org/pub/scm/utils/b4/b4.git/commit/?h=stable-0.14.y&id=e5369681808b

Is it not working on your side? If no, which b4 version are you using?

Cheers,
Matt

Signature · 1 line

Sponsored by the NGI0 Core fund.

Dave Marquardt

author

2026-03-20 15:27 UTC #2 lore raw

Quoted 20 lines · Matthieu Baerts

Quoted 14 lines · Dave Marquardt
I found the message here a little confusing, and had to go code spelunking to figure out what it might mean and how I should answer the Y/N question.
    $ b4 prep --edit-cover
    Waiting for Emacs...
    Invoking git-filter-repo to update the cover letter.
    The previous run is older than a day (/home/davemarq/linux/linux/.git/worktrees/ibmvfc-fpin-bis/filter-repo/already_ran already exists).
    See "Already Ran" section in the manual for more information.
    Treat this run as a continuation of filtering in the previous run (Y/N)? n
    New history written in 612.22 seconds...
    Completely finished after 612.53 seconds.
    Cover letter updated.
Quoted 4 lines
I first searched the b4 manual, and found nothing about "Already Ran". Eventually, on reading the b4 code in ez.py, I found this was from the git-filter-repo package and I should check its manual. I found the code. There's no way to opt out of this check and message.

Quoted 7 lines

Yes, there is: simply by removing the file. That's what b4 is doing for a while, and it has been backported in the last stable version (0.14.3):
https://git.kernel.org/pub/scm/utils/b4/b4.git/commit/?h=stable-0.14.y&id=e5369681808b
Is it not working on your side? If no, which b4 version are you using?

Yeah, this is weird. I'm running 0.15-dev, which is some snapshot of the master. I just looked at the code that invokes RepoFilter, and here's the code:

            frargs = fr.FilteringOptions.parse_args(['--force', '--quiet', '--refs', f'{commit}~1..HEAD'])
            frargs.refs = [f'{commit}~1..HEAD']
            frf = fr.RepoFilter(frargs, commit_callback=fred.callback)

So --force is what should remove the file, and for some reason its not working.

I'll debug at my end to see if I've found a bug.

Thanks!

-Dave

Dave Marquardt

author

2026-03-20 15:50 UTC #3 lore raw

In reply to Matthieu Baerts

Quoted 22 lines · Matthieu Baerts

Hi Dave,
Quoted 14 lines · Dave Marquardt
I found the message here a little confusing, and had to go code spelunking to figure out what it might mean and how I should answer the Y/N question.
    $ b4 prep --edit-cover
    Waiting for Emacs...
    Invoking git-filter-repo to update the cover letter.
    The previous run is older than a day (/home/davemarq/linux/linux/.git/worktrees/ibmvfc-fpin-bis/filter-repo/already_ran already exists).
    See "Already Ran" section in the manual for more information.
    Treat this run as a continuation of filtering in the previous run (Y/N)? n
    New history written in 612.22 seconds...
    Completely finished after 612.53 seconds.
    Cover letter updated.
Quoted 4 lines
I first searched the b4 manual, and found nothing about "Already Ran". Eventually, on reading the b4 code in ez.py, I found this was from the git-filter-repo package and I should check its manual. I found the code. There's no way to opt out of this check and message.

Quoted 7 lines

Yes, there is: simply by removing the file. That's what b4 is doing for a while, and it has been backported in the last stable version (0.14.3):
https://git.kernel.org/pub/scm/utils/b4/b4.git/commit/?h=stable-0.14.y&id=e5369681808b
Is it not working on your side? If no, which b4 version are you using?

Okay, I have this code in my local version, and I think I know why it is not working. This code uses

    gtl = b4.git_get_toplevel()

and b4.git_get_toplevel() uses

gitargs = ['rev-parse', '--show-toplevel']
lines = git_get_command_lines(path, gitargs)

But git-filter-repo uses

git_dir = GitUtils.determine_git_dir(b'.')

and that is

d = subproc.check_output('git rev-parse --git-dir'.split(),
cwd=repo_working_dir).strip()

Since I'm using a Git worktree, "git rev-parse --show-toplevel" and "git rev-parse --git-dir" return different values:

    $ git rev-parse --show-toplevel
    /home/davemarq/linux/ibmvfc-fpin-bis
    $ git rev-parse --git-dir
    /home/davemarq/linux/linux/.git/worktrees/ibmvfc-fpin-bis

So the b4 code is looking in the wrong place.

I'll send a patch for this.

-Dave