Hi, Guido Günther wrote:
> The option is called commit.gpgsign not commit.pgpsign (according to > "man git-config")… [...] > …and it doesn't affect git-commit-tree, that's why "gbp import-orig" is > unaffected since it doesn't use "git commit" but git-commit-tree. So > from gbp's point of view everything is working as expected as far as I > can tell. > > We could add options to explicitly pass "-S" to commit tree but since > git already has machinery for it it should be configurable there I > think (and I can't see a reason why one would have "git commit" sign > commits but not "git commit-tree". This behavior is intentional. Often convenience features like this one are provided in user-facing commands (like "git commit") and not scripting commands (like "git commit-tree"). Part of that is because it is easier to understand the intent behind a user calling a user-facing command. When a script calls a command like commit-tree, we don't have information about the higher-level operation that this was a component of, so we err on the side of predictability. More importantly, making commit-tree use --gpg-sign implicitly would turn a non-interactive command into an interactive one. This would be likely to break some scripts, such as gbp import-orig. Could "gbp import-orig" gain a --sign-commits option to allow a user to explicitly indicate whether they want to pass --gpg-sign to commit-tree? That way, the user intent is clearer. Making it default to true when commit.gpgsign would make sense in that context. Despite how it may seem from the above comments, I am not completely sure about whether "git commit-tree" should default to --gpg-sign when commit.gpgsign is set. It's possible that there's a use case that would warrant it. But for this particular use case, passing the option explicitly from "gbp import-orig" seems preferable. Thanks and hope that helps, Jonathan
