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