Can I add a line to the reflog?

Question

I am in the middle of rebase hell due to a botched git commit --fixup. I think I've identified the source and I'm in a better place than I started. However, if I look at the git reflog, this sequence of 'rebase -i' lines looks just like my previous botched attempts.

Can I add my own line to the reflog? Say something that would look like:

$ git reflog mark '== we are not worse off than we started here =='
$ git reflog -3
cb6536f HEAD@{0}: mark: == we are not worse off than we started here ==
cb6536f HEAD@{1}: rebase -i (finish): fixup! foo: baz the widgets
9db07de HEAD@{1}: rebase -i (pick): fixup! baz: implement widget bazzing

The closest think I can think of is `git commit --fixup HEAD --allow-empty`, though that creates an actual commit that would go away on its own harmlessly on the next `git rebase -i --autosquash` — badp, Apr 21 '16 at 12:49

score 3 · Accepted Answer · answered Apr 21 '16 at 19:34

You may add a new reflog entry at any time using the same command git uses to add new reflog entries, namely git update-ref. This is a "plumbing" (script-oriented) command so it is not very user friendly, and you might want to add your own little wrapper script or alias.

Examples:

git update-ref -m 'mark: whatever' HEAD HEAD
git update-ref -m 'mark: another thing' refs/heads/branch branch
git update-ref -m 'mark: third thing' refs/heads/branch refs/heads/branch
hash=$(git rev-parse refs/heads/branch) && \
   git update-ref -m 'mark: 4' refs/heads/branch $hash

Note that the <ref> (the first non-option argument) must be fully spelled out. The <newvalue> can be anything that resolves to a valid SHA-1, which is why the middle command of the three examples can work, but for safety it is probably best to use the third form (repeat the <ref> exactly) or use an actual SHA-1 hash (fourth form), letting git rev-parse verify that this is in fact a valid branch name.

(When using HEAD you can skip validation since git cannot function at all if HEAD is not a valid name.)

score 0 · Answer 2 · answered Feb 26 '20 at 05:28

As mentioned in this 2020 thread:

There is the option core.logAllRefUpdates, which has the value "always" in more modern versions of Git.
The documentation says:

If the option is set to always, then a missing reflog is automatically created for any ref under refs/.

Now, that assumes that you want reflogs for all your refs, but there's really not much downside to having a reflog and not using it.

Jeff Kings adds:

The current rule is actually to append to any reflog that already exists, or to consult core.logAllRefUpdates when deciding whether to create one that doesn't exist. So I think setting a one-shot config variable like:
git -c core.logAllRefUpdates=always update-ref refs/foo/bar ...
would create the reflog, and then any subsequent updates (even without that config set) would append to it.

You can also do this:
mkdir -p .git/logs/refs/foo/
touch .git/logs/refs/foo/bar
git update-ref refs/foo/bar ...
but I wouldn't recommend it.
When we eventually move to supporting other ref backend formats, they won't necessarily store the logs in the same way.

Can I add a line to the reflog?

2 Answers2