Matthieu Moy <Matthieu.Moy@xxxxxxx> writes:
> Teemu Likonen <tlikonen@xxxxxx> 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.
--
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