Junio C Hamano <gitster@xxxxxxxxx> writes:
> Alexander 'z33ky' Hirsch <1zeeky@xxxxxxxxx> 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.
--
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