Re: [PATCH v2] push: point to 'git pull' and 'git push --force' in case of non-fast forward

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 8, 2009, 16:25 UTC
Message-ID: <7vy6pujmsc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpqab2aqqia.fsf@bauges.imag.fr>

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

Show 20 quoted lines

> Teemu Likonen <tlikonen@iki.fi> writes:
>
>> On 2009-08-08 09:51 (+0200), Matthieu Moy wrote:
>>> 'git push' failing because of non-fast forward is a very common situation,
>>> and a beginner does not necessarily understand "fast forward" immediately.
>>
>>> +		if (nonfastforward) {
>>> +			printf("Push was rejected because it would not result in a fast forward:\n"
>>> +			       "Merge in the remote changes (using git pull) before pushing yours,\n"
>>> +			       "or use git push --force to discard the remote changes.\n"
>>> +			       "See 'non-fast forward' section of 'git push --help' for details.\n");
>>> +		}
>>
>> I'd like to add that some projects that use Git in (partially)
>> centralized manner prefer "git pull --rebase" before "git push".
>
> Right, but I don't think this error message is the place to discuss
> that. Anything involving rebasing should be taken with care, and
> pointing the user to it in a short sentence sounds like "try shooting
> yourself in the foot, and read the man page if it hurts" ;-).

Instead of saying "Merge in", we could say "Integrate" to cover both practices. I also happen to think that the mention of --force falls into the same category as "try shooting and then study if it hurgs".

So how about phrasing it like this?

    Non-fast forward pushes were rejected because you would discard remote
    changes you have not seen.  Integrate them with your changes and then
    push again. See 'non-fast forward' section of 'git push --help'.

I think you can throw in a discussion on --force to the manual page, too.