On Tue, May 03, 2016 at 11:01:11AM -0700, Junio C Hamano wrote:
> Ignoring commit.gpgsign option _obviously_ breaks the backward
> compatibility, but it is easy to follow the standard pattern in
> scripts to honor whatever configuration variable they choose to
> follow. E.g.
>
> case $(git config --bool commit.gpgsign) in
> true) sign=-S ;;
> *) sign= ;;
> esac &&
> git commit-tree $sign ...whatever other args...
>
> Do so to make sure that "git rebase" keeps paying attention to the
> configuration variable, which unfortunately is a documented mistake.
>
> Helped-by: Jeff King <peff@xxxxxxxx>
> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
> ---
> Documentation/git-commit-tree.txt | 4 ++--
> builtin/commit-tree.c | 4 ----
> git-rebase.sh | 5 ++++-
> t/t7510-signed-commit.sh | 13 ++++++++++---
> 4 files changed, 16 insertions(+), 10 deletions(-)
Thanks, this looks good to me[1]. Especially thinking about the rebase
case you handle here makes me more convinced than ever that an option
like "--respect-commit-gpgsign-config" is the wrong path. Because the
ultimate fate for rebase may be something like:
case $(git config --bool rebase.gpgsign) in
true) sign=-S ;;
false) sign= ;;
*)
case $(git config --bool commit.gpgsign) in
true) sign=-S ;;
*) sign= ;;
esac
;;
esac
You _can_ implement that by falling back to --respect... in the "*"
case, but at that point it is not saving much code, and merely making
things unnecessarily confusing.
-Peff
[1] I will say that I am happy with rebase respecting commit.gpgsign
myself. The config I want is really "sign all commits I create", so
I'd end up setting rebase.gpgsign, too, if it existed. But maybe
other people have different workflows.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html