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.

Something to be considered is whether "git rebase -S" should sign *every*
commit in the series or only the *head* commit.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to