Re: [PATCH] merge: refuse to create too cool a merge by default

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 6, 2016, 18:55 UTC
Message-ID: <CA+55aFy-mb00=KGWghx5XXfkv5dChnncoLoJA07f_2Y_or0FOw@mail.gmail.com>
In-Reply-To: <xmqqwpoawpmq.fsf@gitster.mtv.corp.google.com>

On Wed, Apr 6, 2016 at 11:36 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

>
> I was reviewing the topics to merge to 'master', and a thought
> crossed my mind.  Both of our series only refuse to create a merge
> that does not have any common ancestor, but shouldn't the right
> solution refuse to add a new root?

So I think that's an independent thing, and I think you're right, it would be a good feature to have. As a maintainer, it would have caught the whole "my submaintainers did something really odd, I need to talk to them" before-the-fact rather than after-the-fact.

That said, I'm less worried about my submaintainers doing _intentionally_ annoying things, than people doing silly things by mistake.

So if I had a version of git that allowed me to say "don't allow pulls that add a new root commit unless I specify a '--new-root-allowed' flag", then yes, I'd use that. And I guess it might not be too nasty to add: it could be done as part of the object checking pass after downloading the pack. Was that what you were thinking of?

But at the same time, I think the existing series you have, which hopefully results in these things not happening by mistake in the future is the more important piece. I'd rather get good pull requests than get errors and have to tell people "you screwed up, now we'll need to re-do this".

But if you cook something up that checks that there are no new roots in the pull, I'd certainly appreciate that safety net.

               Linus