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

[Junio C Hamano <gitster@pobox.com>]

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

> 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?