Sebastian Götte venit, vidit, dixit 24.04.2013 10:53:
> On 04/23/2013 09:56 PM, Joel Jacobson wrote:
>>> 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?
> 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.

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).

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to