This should read cl_assert_equal_i(1, git_reflog_entrycount(log)). Removing a ref removes its reflog as well. If we don't, that's a bug in our implementation.

Currently, you have to call git_reflog_delete to remove the reflog of a deleted branch.

I'm not exactly sure if that's a bug, though. I like that we're making sure the reflog gets updated, but the fact that there's no way to recover the data makes me want to give the caller the option (and mention this in the docs).

Two branches having the same name doesn't mean that they're the same, and giving it the reflog history of something else is going to cause confusion at best.

Or consider git branch foo && git branch -d foo && git branch foo/bar (or their update-ref equivalents. If we don't remove the reflog in the second command, we can't create the reflog for the third.

Losing the reflog information is indeed something that can be a bit troublesome, but we can't fix it by keeping it in the normal reflog namespace. We'd need an attic where the names/keys don't behave like files and directories.

EDIT: there's been some discussion about this in the git ML, the term there is "reflog graveyard"

Okay, you've convinced me. It shall be fixed.

This technically differs from what git provides, but I'm not sure how we can fix this without extra context:

$ git branch temp4 HEAD~
$ git reflog temp4
b2eb7ec temp4@{0}: branch: Created from HEAD~

I think it's reasonable to deviate a bit here; if the caller wants to provide this context, they are free to.

How about adding to oid to the message? eg. branch: Created from deadbeefcafe...

Hmmm. Might not be worth it as the target oid is already part of the reflog entry... Although that may be a little easier to parse for a user.

Git in this case has more context than we do, but it's not too bad, you can only do so much. If bindings want to optionally take rev-parse-like strings instead of oids, then they could fill in a better default message.

The 'created from X' part seems to be as a way of figuring out what command you run, but as we don't have commands in that sense, I wouldn't worry too much about not having 1-to-1 messages.

I went ahead and started the work to port this to libgit2sharp, and one of the overloads there does the right thing, which makes sense, since it has all the info necessary to do so. This seems like a sensible pattern, so I think I'll just make a stronger recommendation in the doc-comments.

When NULL, a default log message will be generated.

How's this? b3558d8

We have a user-provided signature here, shouldn't we be passing it to the function?

😊 I suppose I should write tests for all of those, shouldn't I?

Done.