Thread (1 message) 1 message, 1 author, 2023-07-07

Re: [PATCH v3 2/2] push: advise about force-pushing as an alternative to reconciliation

From: Junio C Hamano <hidden>
Date: 2023-07-07 18:44:12

Phillip Wood [off-list ref] writes:
Hi Alex

On 06/07/2023 05:01, Alex Henrie wrote:
quoted
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.
This message would also benefit from adding explanation as to why this
change is desirable.
Yes, at least some essence from the lengthy discussion we had in the
review threads for the expected use cases deserve to be summarized
to help future developers who run "git log" (and "git blame") to
find this commit.

Unlike the [1/2] step, where the commands like "status" and
"checkout" that are detached far away from the actual "push" are
affected, this is exactly about "push has failed, now what"
situation, where a change from "you must reconcile" to "if you want
to reconcile, you could do this, but it may be that discarding the
work on the other side is the right thing, if that is just a stale
copy of what you are pushing" is very much welcome.
It makes the advice longer  but the user get a specific suggestion for
their current situation rather than a generic suggestion to delete the
remote changes without discussing the implications. In this case we
know that it was the current branch that was rejected and so should
fill in the branch name in the advice as well.

My main issue with the changes in this series is that they seem to
assume the user is (a) pushing a single branch and (b) they are the
only person who works on that branch. That is a common but narrow case
where force pushing is perfectly sensible but there are many other
scenarios where suggesting "push --force" would not be a good idea.
Yup.  Thanks for a review.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help