Re: [PATCH v2 4/8] builtin/reflog: implement subcommand to write new entries

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 29, 2025, 15:00 UTC
Message-ID: <xmqqseifqbym.fsf@gitster.g>
In-Reply-To: <aIhvcSHrRLG6wcMD@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 11 quoted lines

> There's a big difference though: `git reflog drop` won't ever do
> anything for a reflog that doesn't exist. Consequently, we know that our
> DWIM mechanism can kick in and resolve the reference properly if such a
> reflog exists.
>
> But for `git reflog write` that's not the case, as you can write a
> reflog message for a yet-nonexistent reflog. The DWIM mechanism cannot
> kick in here as there is no reflog. So what do we do in that case? We
> could of course just pick the first DWIM rule, which would be that we
> decide to write the reflog for "refs/heads/$REFNAME". But... I dunno,
> that feels too magicky to m

I concur. Like update-ref, a command that would work on a name that does not yet exist, especially when it is a plumbing-ish low-level command, would be too confusing if it dwimmed based on what names exist already.

I wonder if it is feasible to correct the UI mistake of "git reflog" using the dwim-ref logic, and compensate it by teaching "git branch" and "git tag" options to drop reflog for the thing they act on. At that level, there is nothing to dwim---"branch" is about branches that are either refs/heads/* or (when run with -r) refs/remotes/*. It's sort of like "for-each-ref" requiring the refname from the top, while "branch -l" and "branch -l -r" always limit themselves to the relevant hierarchy.

But it is probably not a good idea and is way too late.