Junio C Hamano <gitster@xxxxxxxxx> writes:
> Matthieu Moy <Matthieu.Moy@xxxxxxx> writes:
>
>> 'git push' failing because of non-fast forward is a very common situation,
>> and a beginner does not necessarily understand "fast forward" immediately.
>>
>> Signed-off-by: Matthieu Moy <Matthieu.Moy@xxxxxxx>
>> ---
>> That may be a bit verbose, but I think it's worth it.
>> ...
>> + if (nonfastforward) {
>> + printf("Some branch push were rejected due to non-fast forward:\n");
>> + printf("Merge the remote changes (git pull) before pushing your's\n");
>> + printf("or use git push --force to discard the remote changes.\n");
>> + }
>
> Although I think the patch identified the right place to make changes, I
> am not sure about what the help message should say.
>
> If the user lacks understanding of what a fast-forward is, I do not think
> giving two choices that would produce vastly different results
Well, there are different levels of mis-understanding of
"fast-forward", and one of them is just a mis-understanding of the
wording.
My experience is that many people understand "there are changes over
there that you don't have so an explicit merge is needed", but would
not necessarily use the wording "fast-forward" for this.
The second line of my message was not only here to point to "git
pull", but had also a subliminal message stating that there are
remote changes ;-).
> Jokes aside, perhaps we could add "see git-push documentation for details"
> to the above message of yours, and add something like this to the
> documentation.
100% convinced that this section in the doc is a good idea. I'm not
totally sure the error message should point to it, because that will
make the message 4 lines long instead of 3, so it may start disturbing
gurus for whom the whole message is useless.
Right now, I have this in my tree:
if (nonfastforward) {
printf("Some push were rejected because it would not result in a fast forward:\n"
"Merge in the remote changes (using git pull) before pushing yours, or\n"
"use git push --force to discard the remote changes.\n"
"See 'non-fast forward' section of 'git push --help' for details.\n");
}
> +Alternatively, you can rebase your change between X and B on top of A,
> +with "git pull --rebase", and push the result back. The rebase will
> +create a new commit D that builds the change between X and B on top of
> +A.
> +
> +----------------
> +
> + B D
> + / /
> + ---X---A
> +
> +----------------
> +
> +Again, updating A with this commit will fast-forward and your push will be
> +accepted.
Maybe add something about --force ? I don't like my wording very much,
but a first try is this:
Lastly, you can decide that the B shouldn't have existed, and delete
it. This is to do with a lot of care, not only because it will discard
the changes introduced in B, but also because if B has been pulled by
someone else, he will have a view of history inconsistant with the
original repository. This is done with the --force option.
--
Matthieu
--
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