Re: [PATCH] Add .gitconfig variable commit.gpg-sign

Joel Jacobson [off-list ref] writes:

On Tue, Apr 23, 2013 at 6:53 PM, Junio C Hamano [off-list ref] wrote:

quoted

I would consider such use of "git -c key=val" a last-resort escape
hatch to work around broken commands that do not implement a proper
escape hatch designed in to help users, unless the "key" is for
something very obscure and not meant for every-day use (read: not
deserving a proper command line override).

Agreed.

We already have --gpg-sign[=<keyid>], so I suggest --no-gpg-sign to
override commit.gpgsign.

Sounds good?

Yup.

And then we would need to add the same option to existing callers of
"git commit" (such as "git rebase") to pass it down the callchain.

But stepping back a bit, I have a suspicion that your upstream
project _only_ cares about what you feed them (either by pushing
your work yourself to them, or telling them to pull from your
repository).  There is no reason for you to be constantly signing
your commits you make during your exploratory development that you
may throw-away in the end.

It _might_ be a better option to just teach "-S" option to "git
rebase" that tells it to replay all the commits with "commit -S",
instead of adding commit.gpgSign configuration.

On Tue, Apr 23, 2013 at 8:25 PM, Junio C Hamano [off-list ref] wrote:

Yup.

And then we would need to add the same option to existing callers of
"git commit" (such as "git rebase") to pass it down the callchain.

Got it.

But stepping back a bit, I have a suspicion that your upstream
project _only_ cares about what you feed them (either by pushing
your work yourself to them, or telling them to pull from your
repository).  There is no reason for you to be constantly signing
your commits you make during your exploratory development that you
may throw-away in the end.

Your suspicions are correct.
But I'm a bit paranoid, so it feels better to sign even local commits.

It _might_ be a better option to just teach "-S" option to "git
rebase" that tells it to replay all the commits with "commit -S",
instead of adding commit.gpgSign configuration.

In my case, I don't do that much exploratory development locally,
so I usually just commit, pull and push.

Always signing everything can't really hurt, can it? Takes a few clock
cycles more, and a few more bytes, but apart from that I don't see any
problems?

On 04/23/2013 09:56 PM, Joel Jacobson wrote:

quoted

But stepping back a bit, I have a suspicion that your upstream
project _only_ cares about what you feed them (either by pushing
your work yourself to them, or telling them to pull from your
repository).  There is no reason for you to be constantly signing
your commits you make during your exploratory development that you
may throw-away in the end.

Your suspicions are correct.
But I'm a bit paranoid, so it feels better to sign even local commits.

quoted

It _might_ be a better option to just teach "-S" option to "git
rebase" that tells it to replay all the commits with "commit -S",
instead of adding commit.gpgSign configuration.

In my case, I don't do that much exploratory development locally,
so I usually just commit, pull and push.

Always signing everything can't really hurt, can it? Takes a few clock
cycles more, and a few more bytes, but apart from that I don't see any
problems?

I have my GPG-keys password-protected, and I would be severely annoyed by
GnuPG password prompts popping up on every commit. I think the -S option
to rebase would be the more elegant way. What could be nice would be a
config option that makes "git push" warn/abort in case I try to push an
unsigned head commit to a repo where I want to have signed commits:

remote.<name>.abortUnsigned

This of course needs an command line override switch.

Something to be considered is whether "git rebase -S" should sign *every*
commit in the series or only the *head* commit.

Sebastian Götte venit, vidit, dixit 24.04.2013 10:53:

On 04/23/2013 09:56 PM, Joel Jacobson wrote:

quoted

quoted

But stepping back a bit, I have a suspicion that your upstream
project _only_ cares about what you feed them (either by pushing
your work yourself to them, or telling them to pull from your
repository).  There is no reason for you to be constantly signing
your commits you make during your exploratory development that you
may throw-away in the end.

Your suspicions are correct.
But I'm a bit paranoid, so it feels better to sign even local commits.

quoted

It _might_ be a better option to just teach "-S" option to "git
rebase" that tells it to replay all the commits with "commit -S",
instead of adding commit.gpgSign configuration.

In my case, I don't do that much exploratory development locally,
so I usually just commit, pull and push.

Always signing everything can't really hurt, can it? Takes a few clock
cycles more, and a few more bytes, but apart from that I don't see any
problems?

I have my GPG-keys password-protected, and I would be severely annoyed by
GnuPG password prompts popping up on every commit. I think the -S option
to rebase would be the more elegant way. What could be nice would be a
config option that makes "git push" warn/abort in case I try to push an
unsigned head commit to a repo where I want to have signed commits:

quoted

remote.<name>.abortUnsigned

This of course needs an command line override switch.

This appears to be more suited for a server side hook (update), or a new
pre-push hook.

Something to be considered is whether "git rebase -S" should sign *every*
commit in the series or only the *head* commit.

The idea is probably to sign a commit that used to signed?

Otherwise, "git commit --amend -S" is your friend, either during rebase
(for individual commits) or after (for the head commit).

Michael

On 04/24/2013 11:51 AM, Michael J Gruber wrote:

Sebastian Götte venit, vidit, dixit 24.04.2013 10:53:

quoted

                                         What could be nice would be a
config option that makes "git push" warn/abort in case I try to push an
unsigned head commit to a repo where I want to have signed commits:

quoted

remote.<name>.abortUnsigned

This of course needs a command line override switch.

This appears to be more suited for a server side hook (update), or a new
pre-push hook.

Ok, here it is ;)
I replaced the previous sample hook code because it did only check for commits
containing "WIP" in their messages which I think is not terribly useful (and
can easily be added to this script. I also added a missing colon that caused my
shell to complain about an empty if.
This patch applies to the current master as it requires the new GPG %G? pretty
placeholder output.

Signed-off-by: Sebastian Götte <redacted>
---
 templates/hooks--pre-push.sample | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/templates/hooks--pre-push.sample b/templates/hooks--pre-push.sample
old mode 100644
new mode 100755
index 15ab6d8..08a72df
--- a/templates/hooks--pre-push.sample
+++ b/templates/hooks--pre-push.sample

@@ -16,20 +16,19 @@
 #
 #   <local ref> <local sha1> <remote ref> <remote sha1>
 #
-# This sample shows how to prevent push of commits where the log message starts
-# with "WIP" (work in progress).
+# This sample shows how to prevent pushing commits without good GPG signatures
 
 remote="$1"
 url="$2"
 
 z40=0000000000000000000000000000000000000000
+ec=0
 
-IFS=' '
 while read local_ref local_sha remote_ref remote_sha
 do
 	if [ "$local_sha" = $z40 ]
 	then
-		# Handle delete
+		: # Handle delete
 	else
 		if [ "$remote_sha" = $z40 ]
 		then

@@ -40,14 +39,13 @@ do
 			range="$remote_sha..$local_sha"
 		fi
 
-		# Check for WIP commit
-		commit=`git rev-list -n 1 --grep '^WIP' "$range"`
-		if [ -n "$commit" ]
-		then
-			echo "Found WIP commit in $local_ref, not pushing"
-			exit 1
-		fi
+		commits=`git log --format="%G? %h" "$range" | grep -v '^G' | cut -d\  -f2`
+		for commit in $commits
+		do
+			echo "Commit $commit does not have a good GPG signature"
+			ec=1
+		done
 	fi
 done
 
-exit 0
+exit $ec

-- 
1.8.2