git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Alexander 'z33ky' Hirsch <1zeeky@gmail.com>
Cc: git@vger.kernel.org, "brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH] rebase: add --verify-signatures
Date: Wed, 16 Dec 2015 10:12:12 -0800	[thread overview]
Message-ID: <xmqqfuz2e003.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20151216133915.GA3586@blarch> (Alexander Hirsch's message of "Wed, 16 Dec 2015 14:39:15 +0100")

Alexander 'z33ky' Hirsch <1zeeky@gmail.com> writes:

> On Thu, Dec 10, 2015 at 11:53:45AM -0800, Junio C Hamano wrote:
>
>> In a workflow that is built around "pull --rebase", you are _given_
>> the authoritative history with all the good things from another
>> place and then you rebuild your own work on top of it.  The sanity
>> and cleanliness of what you built on top is given, and rejecting it
>> at that point would not help you make further progress in any way,
>> as that is a published history that is shared and more authoritative
>> than what you have.
>
> Well, the rejection would not refer to the work you put on top, but to
> the commits you want to base your work on.
> If validation fails, then an empty commit that is signed can be
> committed on top of the previously unsigned branch if commit rewriting
> is not allowed.

I do not quite understand how that would help anything.  I do not
personally believe in projects that wants to sign each and every
commit, but to them, "an empty signed commit on top" would not fix
anything once they have an unsigned commit at the tip of a public
branch.  And for those that care about only the tip to be signed,
instead of adding such an empty commit, you would rebuild and sign
your work on top of that unsigned public tip and push back---at
which point the tip of the public branch would have a signature from
you.  So such an empty signed commit would either not help, or not
necessary, to make the resulting history kosher again.

  reply	other threads:[~2015-12-16 18:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10 13:03 [PATCH] rebase: add --verify-signatures Alexander 'z33ky' Hirsch
2015-12-10 19:11 ` Junio C Hamano
2015-12-10 19:53   ` Junio C Hamano
2015-12-16 13:39     ` Alexander 'z33ky' Hirsch
2015-12-16 18:12       ` Junio C Hamano [this message]
2015-12-17  1:04         ` Alexander 'z33ky' Hirsch
2015-12-17 18:22           ` Junio C Hamano
     [not found]             ` <20151221140414.GA3422@netblarch.tu-darmstadt.de>
     [not found]               ` <xmqqvb7re55d.fsf@gitster.mtv.corp.google.com>
2015-12-22 23:12                 ` Alexander 'z33ky' Hirsch

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqfuz2e003.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=1zeeky@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).