Re: first parent, commit graph layout, and pull merge direction

From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>,
	"Felipe Contreras" <felipe.contreras@gmail.com>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
	"John Keeping" <john@keeping.me.uk>,
	"Andreas Krey" <a.krey@gmx.de>,
	"John Szakmeister" <john@szakmeister.net>,
	"Git Mailing List" <git@vger.kernel.org>
Subject: Re: first parent, commit graph layout, and pull merge direction
Date: Fri, 24 May 2013 21:47:19 +0100	[thread overview]
Message-ID: <9C8FD0BE27314D72A629025EFFF58848@PhilipOakley> (raw)
In-Reply-To: 7vli74baym.fsf@alter.siamese.dyndns.org

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Friday, May 24, 2013 5:26 PM
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> ... but I don't see why something small like that
>> wouldn't make sense:
>>
>> The pull was not fast-forward, please either merge or rebase.
>
> OK, I think I got what John was getting at and this single liner
> message is a good summary of it.
>
> Instead of telling them "you cannot push this thing without losing
> history from the location you are pushing to; you need to become up
> to date with respect to them before pushing" upon seeing a non ff
> push failure, we can tell them "you cannot update your history to
> what the place you get new changes from has without losing your
> history; you need to integrate the two".
>
> Initially I said limiting "git pull" to "--ff-only" by default did
> not make sense, but when we view it that way, I now see how such a
> default makes sense.
>
> In another subthread, John Szakmeister mentioned that the "please
> 'git pull' first" message that a "push" gives when it stops due to
> non-ff nudges the users in a wrong direction, because they often
> take that 'git pull' too literally (e.g. 'pull --rebase' may be
> necessary in their project, not 'git pull<ENTER>').
>
> The original message deliberately avoided mentioning 'git pull' for
> that exact reason, but in mid 2010 we made it worse.  The log of
> that change says that it attempted to
>
>    ... remains fuzzy to include "git pull", "git pull --rebase" and
>    others, but directs the user to the simplest solution in the
>    vast majority of cases.
>
> but this thread shows that it did not work; the simplest solution
> was a wrong one.  The message also may need to be rethought to
> complement this direction being proposed for "pull".
> --

Perhaps offer "git pull ....", which suggests that the user should 
consider what pull parameters to provide and if taken literally should 
barf with the four dots.

Philip