diff options
| author | Alex Henrie <alexhenrie24@gmail.com> | 2023-07-12 22:41:15 -0600 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2023-07-13 09:14:58 -0700 |
| commit | c577d65158aa78817a59a58649bb381f2daaa88d (patch) | |
| tree | f1f44f53e9753276189bd023ce1c0757e623c16b /commit-graph.c | |
| parent | remote: don't imply that integration is always required before pushing (diff) | |
| download | git-c577d65158aa78817a59a58649bb381f2daaa88d.tar.gz git-c577d65158aa78817a59a58649bb381f2daaa88d.zip | |
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>
Diffstat (limited to 'commit-graph.c')
0 files changed, 0 insertions, 0 deletions