Re: What's cooking in git.git (topics)

Nicolas Pitre <nico@cam.org> writes:

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'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.