It'd be awesome if you could make git_reference_create use this.

@carlosmn Actually @vmg was rather in favor of exposing a set of separate functions and keep git_reference_create() and git_reference_symbolic_create() as they are.

I of course mean git_commit_create.

You mean adding a git_commit_create_with_log()? Otherwise, it'd be complex to generate the proper message for commit or amend.

Fair enough, that keeps the semantics of a part failing simpler for us.

You're right, we don't know whether it is an amend or a newly-created branch, so we wouldn't produce the same output as git.

This makes the first argument of git_commit_create much less helpful though, as every user should leave it blank and update the reflog themselves, which requires you to hold the right git_reference * anyway.

@cmn If that makes sense, I'd rather work incrementally and tackle the git_commit_create_with_log() in a separate PR.

Sure, I was just thinking out loud

I would prefer if this PR came in conjunction with:

1. Making the reflog API part of the refdb abstraction.
2. Making the on-disk reflog API allow appends without having to parse the reflog beforehand.

@carlosmn is taking this over in another PR. Following there.