Re: git pull with "no common commits" : danger?

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 8, 2010, 06:20 UTC
Message-ID: <7v1veq8nyf.fsf@alter.siamese.dyndns.org>
In-Reply-To: <v2t3abd05a91004071856s5811e086q17241996a359e172@mail.gmail.com>

Aghiles <aghilesk@gmail.com> writes:

> I mistakenly pulled a project into another project. I had the
> "warning: no common commits" but the pull did proceed.
> I am wondering if, from a usability point of view, it would be
> best to avoid doing so by default.

Refusing this without an escape hatch would regress two minor but valid workflows.

 1. "a cross-project merge" like 5569bf9 (Do a cross-project merge of Paul
    Mackerras' gitk visualizer, 2005-06-22) aka "The coolest merge ever".
    Being able to do this kind of merge after the fact is the whole point
    of allowing merges between two histories with no common commits.

 2. A not so uncommon newbie mistake sequence:

    $ git init
    $ git pull $there

    instead of the usual

    $ git clone $there
    
    which was an actual complaint that led to the "merge into emptiness"
    behaviour of "git pull" in such a case added as a new feature.

If we were to forbid a "nothing in common" merge by default and add an option to explicitly allow it on demand, I would not be worried too much about the first use case. Anybody who runs a cross-project merge has already learned git well enough that having to add an extra option is not a problem.

But I would be unhappy if I have to be the one to hear complaints from newbies who are now forced to add an obscure option to his "git pull" in the second case.

So this is not so cut-and-dried from the usability point of view as you seem to think.