create reflog for reflog-less ref

Hi,

I wanted to ask on this list if there are any supported ways to create a reflog for an existing ref that doesn't already have a reflog.

This is more likely to come up for refs not in the standard set (i.e. HEAD, branches and remote-tracking branches), since reflogs aren't created by default for those refs.

The only workaround I could think of is using git-update-ref to delete the ref, and then immediately recreate it using the `--create-reflog` option (if that option is needed), e.g.:

$ git update-ref -d refs/foo/bar $ git update-ref -m "my message" --create-reflog refs/foo/bar <SHA>

This seems hacky though because it forces you to pass through a state where the ref no longer exists. It also requires you to get the ref's SHA first.

This Stack Overflow reply from 2016 suggests the idea of using `git update-ref -m MSG REF REF` to add lines to an existing reflog: https://stackoverflow.com/questions/36770141/can-i-add-a-line-to-the-reflog/36778898#36778898 But it doesn't seem to work to create a reflog (and only seemed to work for me in limited circumstances otherwise, like adding to HEAD's reflog). (I tried with version 2.25.0.)

Any thoughts?

Thanks, --Chris

On 2020-02-26 at 01:07:35, Chris Jerdonek wrote:

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.

On Wed, Feb 26, 2020 at 02:39:09AM +0000, brian m. carlson wrote:

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.

-Peff

On Tue, Feb 25, 2020 at 7:47 PM Jeff King <peff@peff.net> wrote:

Thanks for the suggestions both of you. I didn't know about "always." It looks like it was added in 2.12.0: https://github.com/git/git/blob/master/Documentation/RelNotes/2.12.0.txt#L129

After experimenting a bit more, I seem to be finding that--

* The "one-shot" `-c core.logAllRefUpdates=always` approach only seems
to work with git-update-ref if you're *changing* the SHA with
update-ref, and
* Passing `--create-reflog` also seems to work like the one-shot
config approach (again, as long as you're changing the SHA).

I feel like these options are still wanting.. If you want to add a missing reflog without changing the ref, these approaches still seem to require you to temporarily change it to something different (as did the delete-create approach I stated in my first email). It would be nice to be able to create (or append to) the reflog without having to change where the ref is pointing. Or maybe I'm missing a variation that will do this..

--Chris

On Tue, Feb 25, 2020 at 11:18:39PM -0800, Chris Jerdonek wrote:

No, I don't think there is a variation that will do that. You'd have to wait for the next update.

The "touch" trick I showed would work for that, but it's not going to be portable going forward. I don't think it would be a bad idea to have some way of triggering a "noop" reflog update via update-ref, where we either create the reflog as empty, or insert a pointless entry going from the current sha1 to itself. But AFAIK that doesn't exist right now.

-Peff

On Wed, Feb 26, 2020 at 1:47 AM Jeff King <peff@peff.net> wrote:

Thanks. By the way, this functionality does already seem to exist for ref HEAD:

$ git update-ref -m my-message HEAD HEAD $ git reflog HEAD 3ccacdc (HEAD -> master) HEAD@{0}: my-message ...

I don't know why it would work for HEAD though and what's different about the mechanism. I thought it might be because it's a symbolic ref, but it didn't work for other symbolic refs when I tried (even ones that already had a reflog).

--Chris

On Wed, Feb 26, 2020 at 02:21:59AM -0800, Chris Jerdonek wrote:

I suspect that wasn't really intentional, but just a by-product of the way we treat HEAD's reflog specially (when we update any other ref, if HEAD points to it, we'll update the HEAD reflog, too). But I could be wrong (you'd have to dig in the commit history around that code).

-Peff