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 <1ze...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
