Re: [PATCH] builtin/reflog: say "would prune" for named refs with --dry-run

From: Patrick Steinhardt <ps@pks.im>
Date: Oct 29, 2026, 12:18 UTC
Message-ID: <auM5oUilcWRuWhDA@pks.im>
In-Reply-To: <20261024013850.66448-1-laveeshb@laveeshbansal.com>

On Fri, Oct 23, 2026 at 06:38:50PM -0700, Laveesh Bansal wrote:

Show 14 quoted lines

> With --dry-run --verbose, "git reflog expire --all" reports the entries
> it would remove as "would prune", but when refs are named on the command
> line it reports them as "prune", which looks as if they were removed:
> 
>     $ git reflog expire --dry-run --verbose --expire=now HEAD
>     prune commit (initial): first
> 
> Nothing is removed in either case, only the label is wrong. This was
> reported at [1].
> 
> fcd2c3d9d8 (reflog + refs-backend: move "verbose" out of the backend,
> 2021-12-22) added dry_run to struct expire_reflog_policy_cb and set it
> in the --all loop, but not in the loop for named refs. Set it there
> too.

Phew, kind of lucky that it's only the message and not us accidentally pruning stuff.

> Add tests for named refs and --all. No test checked the keep/prune
> wording before.

Tiny nit, not worth a reroll: this paragraph doesn't really add a ton of value, as it's self-evident from the patch.

Show 15 quoted lines

> diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
> index 93b5b49e1d..998a7e8667 100755
> --- a/t/t1410-reflog.sh
> +++ b/t/t1410-reflog.sh
> @@ -240,6 +240,40 @@ test_expect_success 'reflog expire --dry-run should not touch reflog' '
>  	check_fsck "missing blob $F"
>  '
>  
> +# A dry run only ever says "keep" or "would prune".
> +check_dry_run_output () {
> +	test_grep "^would prune " "$1" &&
> +	sed -e "/^keep /d" -e "/^would prune /d" \
> +		-e "/^Marking reachable objects/d" "$1" >unexpected &&
> +	test_must_be_empty unexpected
> +}

Okay, this is quite defensive in that it both checks that we print "would prune" but none of the other lines. We could have made it even more defensive by filtering out "would prune" lines and then testing that the result is empty. But this here is certainly good enough, I'd say.

So overall this looks good to me as-is, thanks!

Patrick