Git has defaults for if the user.name and user.email configuration options aren't set, but these aren't implemented by libgit2. They make the case that these are an implementation detail of Git, which is entirely correct. Fortunately, git-absorb doesn't really need signatures in order to function. We just lose the author check, and create our temporary commits using a dummy signature. Since they're temporary anyway, this doesn't matter.
Now, since git-absorb is intended to be used as a subcommand of the Git CLI, think it would actually make more sense for it to use Git's default signature implementation, rather than libgit2's. This would make it more consistent with every other git command. Git provides a nice plumbing API to get this value: git var GIT_AUTHOR_IDENT. So, in my mind the more correct fix would actually be to use that, but that would require spawning a git process, which git-absorb doesn't currently do. Hence this more conservative patch. I don't think it would be a big problem though -- it's very unlikely git-absorb would ever be used without git being available.
Git has defaults for if the user.name and user.email configuration options aren't set, but these aren't implemented by libgit2. They make the case that these are an implementation detail of Git, which is entirely correct. Fortunately, git-absorb doesn't really need signatures in order to function. We just lose the author check, and create our temporary commits using a dummy signature. Since they're temporary anyway, this doesn't matter.
Now, since git-absorb is intended to be used as a subcommand of the Git CLI, think it would actually make more sense for it to use Git's default signature implementation, rather than libgit2's. This would make it more consistent with every other git command. Git provides a nice plumbing API to get this value:
git var GIT_AUTHOR_IDENT. So, in my mind the more correct fix would actually be to use that, but that would require spawning a git process, which git-absorb doesn't currently do. Hence this more conservative patch. I don't think it would be a big problem though -- it's very unlikely git-absorb would ever be used without git being available.