> I am not sure if that is a good idea in general, though. That "if > you just rebased" applies only to the case where you rebased your > topic branch. If you forked to work on topic from the upstream's > primary integration branch, worked on that topic, and then rebased > your topic on top of the updated upstream integration branch (which > contains new work from others since you forked and while you were > working on that topic), you do not want to force. force-with-lease > may help you avoid overwriting and discarding others work, but the > only sensible next step in such a case is to pull-rebase again, > which will rebase your work on the topic to build on these recent > work from others. Indeed, there may be more complicated cases. I think the key is whether the tip of your current branch is really behind its remote counterpart. How about we update the advice like this: Updates were rejected because the tip of your current branch is behind its remote counterpart. If you want to integrate the remote changes, use 'git pull' before pushing again. If this is not the case, you may consider `git push --force-with-lease`. See the 'Note about fast-forwards' in 'git push --help' for details. Then, we add a more detailed explanation in the ‘git push —help’ message.
