Nicolas Pitre <nico@xxxxxxx> writes:
> Yet the message itself is not totally accurate either, since "need to
> pull" might have to be "need to force" in some cases.
We used to say only "this is not a fast-forward", and did not
mention "what next". Later we added "maybe you want to pull
first?" without making it clear enough that the reason why the
suggestion may or may not apply to the user is because it
depended largely on the user's workflow. It probably was a
mistake and not mentioning "what next" at all might have been
less confusion-prone. I dunno.
> I think that would be better to append a single line at the end of the
> display with a clue about what "non fast forward" means.
I'd agree, but having said all the above, I am not entirely
happy not mentioning "what next" at all.
There are two equally valid "what next" after your push is
rejected due to non-fast-forwardness.
(1) You know what you are doing.
- You are pushing into a "back-up" repository, not for a
public consumption.
- You are pushing a branch that are advertised to rebase and
rewind into your own publishing repository, and other
people interacting with the branch know about this.
- You pushed a wrong head there very recently and are fairly
confident that nobody has seen that mistake, and pushing
the correct one to fix the mistake.
In these cases, forcing the push is the right solution
(except that the third one is dubious, because it depends
heavily on the "fairly confident" part).
(2) You were building on a stale head, and were indeed about to
lose others' changes with a non-fast-forward push.
The right solution is to rebuild what you push so that you
will not lose others' changes. Rebuilding can take two
different forms:
- You may want to git-fetch and rebase your work on top of
others'.
- You may want to git-pull, which will merge your work with
what others did.
But of couse the above is way too long as the help text.
Does the user-manual talk about this? It has a really good
description of how to notice when a merge is not resolved
automatically and what to do next ("Resolving a merge" section).
Perhaps we can enhance "Pushing changes to a public repository"
section to include "what if the push is refused" information.
-
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
