Re: Newbie grief

From: Illia Bobyr <ibobyr@blizzard.com>
Date: May 4, 2012, 01:01 UTC
Message-ID: <4FA32A6A.4070007@blizzard.com>
In-Reply-To: <4FA3090D.5080406@palm.com>

On 5/3/2012 3:39 PM, Rich Pixley wrote:

Show 28 quoted lines

> On 5/3/12 15:33 , Rich Pixley wrote:
>> On 5/3/12 14:13 , Junio C Hamano wrote:
>>> Ronan Keryell<Ronan.Keryell@hpc-project.com>   writes:
>>>>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich 
>>>>>>>>> Pixley<rich.pixley@palm.com>   said:
>>>>       Rich>   * the hg error messages are straightforward, clear, 
>>>> and don't
>>>>       Rich>   require any deep knowledge of the source code control 
>>>> system
>>>>       Rich>   or it's limitations.  (I still don't understand what 
>>>> the git
>>>>       Rich>   message on collision is saying.)
>>>>
>>>> This is a very good suggestion.
>>>> ...
>>>> At least, print a simpler message with some typical use case causing
>>>> this and some workflow ideas before the detailed explanation.
>>> It indeed is a good starting point to make a suggestion, but there is
>>> nothing actionable in the above by itself, especially since "typical 
>>> use
>>> case" is quite different for different Git users.
>> How about, "Your push can't be made because it would cause an
>> irreconcilable collision.  You probably want to pull and merge before
>> attempting to push again."
>
> Er... "Your push can't be made because it would cause an 
> irreconcilable collision.  You probably want to fetch and merge before 
> attempting to push again."

While this error message makes more sense to you at this point it is not entirely true. The collision is not irreconcilable and may not even be a collision. For example, if you just rebased, it is not a collision from a more abstract point of view.

It is just a "non-fast forward" move of a branch tip. This term describes what happens precisely :)

It is true, that the term is non obvious to the new comers. One may google and get an explanation of the error pretty quickly. First hit for "git non fast forward error" gives an explanation from a new comer point of view for the simplest case.

Another option is to change the way git "talks". AFAIR there were a number of attempts to come up with a new dictionary for git. I am not sure if any of the attempts were complete as it is not that easy. Changing just one error message at a time would make it less consistent as a concept of "fast forward" moves is used in other places. For example, git merge has --ff and --no-ff options that stand for "fast forwrad" and "no fast forward" respectively.

Illia Bobyr