Re: Newbie grief

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 5/3/2012 3:39 PM, Rich Pixley wrote:
> On 5/3/12 15:33 , Rich Pixley wrote:
>> On 5/3/12 14:13 , Junio C Hamano wrote:
>>> Ronan Keryell<Ronan.Keryell@xxxxxxxxxxxxxxx>   writes:
>>>>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich 
>>>>>>>>> Pixley<rich.pixley@xxxxxxxx>   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--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google