All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: "Sebastian Götte" <jaseg@physik.tu-berlin.de>
Cc: Joel Jacobson <joel@trustly.com>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] Add .gitconfig variable commit.gpg-sign
Date: Wed, 24 Apr 2013 11:51:12 +0200	[thread overview]
Message-ID: <5177AB10.30209@drmicha.warpmail.net> (raw)
In-Reply-To: <51779DA1.7080606@physik.tu-berlin.de>

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

  reply	other threads:[~2013-04-24  9:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAASwCXf3YHmdQ_eSkShyzn5VniO=ufm3VTqV1JVOUN610bzE_A@mail.gmail.com>
2013-04-22 23:43 ` [PATCH] Add .gitconfig variable commit.gpg-sign Junio C Hamano
2013-04-23  0:00   ` Joel Jacobson
2013-04-23 11:37     ` Michael J Gruber
2013-04-23 17:53       ` Junio C Hamano
2013-04-23 17:58         ` Joel Jacobson
2013-04-23 19:25           ` Junio C Hamano
2013-04-23 19:56             ` Joel Jacobson
2013-04-24  8:53               ` Sebastian Götte
2013-04-24  9:51                 ` Michael J Gruber [this message]
2013-04-24 17:30                   ` [PATCH 1/1] templates: pre-push hook: check for missing GPG signatures (was: Re: [PATCH] Add .gitconfig variable commit.gpg-sign) Sebastian Götte
2013-04-24 19:54                     ` [PATCH 1/1] templates: pre-push hook: check for missing GPG signatures Junio C Hamano
2013-04-25 12:19                       ` [PATCH v2 0/1] " Sebastian Götte
2013-04-25 16:50                         ` Junio C Hamano
     [not found]                       ` <cover.1366890748.git.jaseg@physik-pool.tu-berlin.de>
2013-04-25 12:19                         ` [PATCH v2 1/1] " Sebastian Götte
2013-04-23 14:01   ` [PATCH] Add .gitconfig variable commit.gpg-sign Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5177AB10.30209@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jaseg@physik.tu-berlin.de \
    --cc=joel@trustly.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.