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

From: Junio C Hamano <[email-masked]>
Date: Tue, 29 Jul 2025 08:00:01 -0700

Patrick Steinhardt <[email-masked]> writes:

> 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.