git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] rebase: add --verify-signatures

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 10, 2015, 19:53 UTC
Message-ID
<xmqqy4d2gjw6.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<xmqq37vai0ev.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 16 quoted lines
> Alexander 'z33ky' Hirsch <1zeeky@gmail.com> writes:
>
>> +	if test -n "$rebase_root"
>> +	then
>> +		foreign_revisions="$orig_head..$onto"
>> +	else
>> +		foreign_revisions="$orig_head..${restrict_revision-$upstream}"
>> +	fi
>> +
>> +	for cmt in $(git rev-list --reverse "$foreign_revisions")
>> +	do
>> +		if ! git log -1 --pretty=format:'%G?%n%GS' "$cmt" |
>
> I do not think this matches what the corresponding option in "git
> merge" does, where the only tips of the histories being merged are
> checked.

Having said that, I somehow doubt that verify-signatures is a feature that is desirable in a workflow around "pull --rebase" in the larger picture. If you step back a bit, in a "merge" based workflow, you are the keeper of the sanity, cleanliness, and all the good things in the authoritative history when doing a "git pull". That is why you would want to validate what gets merged from another place and in that context having --verify-signatures may make sense (and it might even make more sense if the code did so for all new commits, not just the tip, but that is a separate topic). If the validation fails, you would tell the owner of that side branch you just attempted to pull from to get her act together before asking to be pulled again. There is a clear path to make further progress after the validation fails.

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.

Hence, while I 100% agree with Brian's "it is not there because nobody bothered to add the corresponding option on the rebase side", I do not necessarily think "nobody bothered" is the same as "they were too lazy"--perhaps some people thought about doing it, and then decided not to, because the option made no sense when they stepped back to look at the larger picture.

Previous: Junio C HamanoNext: Alexander 'z33ky' Hirsch
Message 3 of 8 in “rebase: add --verify-signatures”
  1. rebase: add --verify-signaturesAlexander 'z33ky' Hirsch, Dec 10, 2015
  2. Junio C HamanoDec 10, 2015
  3. Junio C HamanoDec 10, 2015
  4. Alexander 'z33ky' HirschDec 16, 2015
  5. Junio C HamanoDec 16, 2015
  6. Alexander 'z33ky' HirschDec 17, 2015
  7. Junio C HamanoDec 17, 2015
  8. Alexander 'z33ky' HirschDec 22, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.