Patrick Steinhardt <ps@xxxxxx> 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.
