> Le 28 juil. 2025 à 11:37, Kristoffer Haugsbakk <kristofferhaugsbakk@xxxxxxxxxxxx> a écrit :
>
> On Fri, Jul 25, 2025, at 08:58, Patrick Steinhardt wrote:
>> While we provide a couple of subcommands in git-reflog(1) to remove
>> reflog entries, we don't provide any to write new entries. Obviously
>> this is not an operation that really would be needed for many use cases
>> out there, or otherwise people would have complained that such a command
>> does not exist yet.
>
> This command will allow you to write a simpler unique marker (without
> having to make a marker-ref for a ref) that can be used to find back to
> a specific point.
>
> I’ve had some use for that. I used git-update-ref(1) for that because
> of `-m` (as well as plumbing-for-scripting).
>
>> diff --git a/Documentation/git-reflog.adoc
>> b/Documentation/git-reflog.adoc
>> index c3801b82fb6..c8389810273 100644
>> --- a/Documentation/git-reflog.adoc
>> +++ b/Documentation/git-reflog.adoc
>> @@ -12,6 +12,7 @@ SYNOPSIS
>> git reflog [show] [<log-options>] [<ref>]
>> git reflog list
>> git reflog exists <ref>
>> +git reflog write <ref> <old-oid> <new-oid> <message>
>> git reflog delete [--rewrite] [--updateref]
>> [--dry-run | -n] [--verbose] <ref>@{<specifier>}...
>> git reflog drop [--all [--single-worktree] | <refs>...]
>> @@ -47,6 +48,12 @@ The "exists" subcommand checks whether a ref has a
>> reflog. It exits
>> with zero status if the reflog exists, and non-zero status if it does
>> not.
>> +The "write" subcommand writes a single entry to the reflog of a given
>> +reference. This new entry is appended to the reflog and will thus become
>> +the most recent entry. Both the old and new object IDs must not be
>> +abbreviated and must point to existing objects. The reflog message gets
>> +normalized.
>> +
>
> You have to give the full refname to this subcommand. `git reflog write
> ... branch <msg>` will update the reflog for the one-level ref `branch`.
> But I’m used to using git-reflog(1) with a name like `branch` and it
> using `refs/heads/branch` if it exists. At least that’s how the default
> `git reflog show` behaves.
>
> Which means that
>
> git reflog write ... refs/heads/branch <msg>
> git reflog branch
>
> Will show that written reflog.
>
> Whereas this
>
> git reflog write ... branch <msg>
> git reflog branch
>
> Will show one entry since `branch` is the one-level ref `branch`, not
> `refs/heads/branch`. Now it looks like `write` truncated the reflog and
> wrote a new reflog message (if you mistakenly think that `branch` is a
> branch).
This quirk of update-ref bit me the first few times I used it, too. I think it’s at least documented there though.
>
> It isn’t clear to me how the current doc guides me in the correct
> direction here.
>
> I tried `git reflog drop`[1] and it can deal with a branch like
> `branch`. It doesn’t need to be told `refs/heads/branch`.
(Partly responding to comments about what to do with this) I think consistency would be best, and since “git reflog branch” is not abnormal we should continue to allow that.
>
>> The "delete" subcommand deletes single entries from the reflog, but
>> not the reflog itself. Its argument must be an _exact_ entry (e.g. "`git
>> reflog delete master@{2}`"). This subcommand is also typically not used
