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

[Alexander 'z33ky' Hirsch <1zeeky@gmail.com>]

Sorry, I didn't do a group-reply in my last mail.

On Mon, Dec 21, 2015 at 03:46:54PM -0800, Junio C Hamano wrote:
> Alexander 'z33ky' Hirsch <1zeeky@gmail.com> writes:
> 
> > On Thu, Dec 17, 2015 at 10:22:20AM -0800, Junio C Hamano wrote:
> >> I suspect that you are missing the bigger workflow issues, if you
> >> think this and merge are the same.
> >> 
> >> git-merge will check the other history on the side branch that you
> >> are merging _into_ the trunk, to give you an opportunity to reject
> >> what does not pass and keep the trunk sane without doing anything
> >> else.  How you (or others who asked you to pull) clean up the side
> >> branch is outside the scope of its verification.
> >> 
> >> Your change to "git pull --rebase" checks the other way---the
> >> history, which is already the trunk, onto which your work will be
> >> rebased.  There is nothing you can do without messing with the trunk
> >> if the validation did not pass, be it with a rewind-and-rebuild or a
> >> sealing empty commit which is pointless.
> >
> > It would still make sense for long-lived development branches that
> > contain experimental or controversial features, or for forks/private
> > copies that add a couple of commits onto a branch. Merging is certainly
> > an option, but I don't see why rebasing would be a wrong alternative.
> 
> Nobody says rebase is a wrong alternative.
> 
> It is just the time you decide to rebase is a wrong time to check,
> iow, too late, for the validation of the tip.

In that case I would like to submit a patch that warns or even errors in
case both --rebase and --verify-signatures is passed to git-pull.
I think an error would be appropriate, but in theory this could break
scripts that have done that, albeit it probably didn't do what the user
expected, and I don't know git's policy about breaking something like
this.