push: don't imply that integration is always required before pushing
commitc577d65158aa78817a59a58649bb381f2daaa88d
authorAlex Henrie <alexhenrie24@gmail.com>
Thu, 13 Jul 2023 04:41:15 +0000 (12 22:41 -0600)
committerJunio C Hamano <gitster@pobox.com>
Thu, 13 Jul 2023 16:14:58 +0000 (13 09:14 -0700)
treef1f44f53e9753276189bd023ce1c0757e623c16b
parentd92304ff5cfdca463e9ecd1345807d0b46d6af33
push: don't imply that integration is always required before pushing

In a narrow but common case, the user is the only author of a branch and
doesn't mind overwriting the corresponding branch on the remote. This
workflow is especially common on GitHub, GitLab, and Gerrit, which keep
a permanent record of every version of a branch that is pushed while a
pull request is open for that branch. On those platforms, force-pushing
is encouraged and is analogous to emailing a new version of a patchset.

When giving advice about divergent branches, tell the user about
`git pull`, but don't unconditionally instruct the user to do it. A less
prescriptive message will help prevent users from thinking that they are
required to create an integrated history instead of simply replacing the
previous history. Also, don't put `git pull` in an awkward
parenthetical, because `git pull` can always be used to reconcile
branches and is the normal way to do so.

Due to the difficulty of knowing which command for force-pushing is best
suited to the user's situation, no specific advice is given about
force-pushing. Instead, the user is directed to the Git documentation to
read about possible ways forward that do not involve integration.

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/push.c