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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 6, 2016, 18:36 UTC
Message-ID: <xmqqwpoawpmq.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CA+55aFz7309BkfHjD5H7tp9WE0yf1VWncxfmB3hgimJ00fbT-Q@mail.gmail.com>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 17 quoted lines

> On Fri, Mar 18, 2016 at 1:21 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> While it makes sense to allow merging unrelated histories of two
>> projects that started independently into one, in the way "gitk" was
>> merged to "git" itself aka "the coolest merge ever", such a merge is
>> still an unusual event.  Worse, if somebody creates an independent
>> history by starting from a tarball of an established project and
>> sends a pull request to the original project, "git merge" however
>> happily creates such a merge without any sign of something unusual
>> is happening.
>>
>> Teach "git merge" to refuse to create such a merge by default,
>> unless the user passes a new "--allow-unrelated-histories" option to
>> tell it that the user is aware that two unrelated projects are
>> merged.
>
> Heh. I had a separate set of patches for you, but hadn't sent them out
> because of the other test failures (which you also worked out).

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? That is, somebody may

 - Create a new root by mistake;
 - Pull from you to update, with --allow-unrelated-histories option;
 - Optionally, build more history on top of it; and then finally
 - Ask you to pull without telling you that there is a new root.

Wouldn't the "git pull" you do in response to this pull request have a common ancestor (i.e. the tip of what he pulled from you in the second step) and evade this check?