Add dwim push that uses upstream vs pushRemote or block upstream push if pushRemote exists

[darkfeline]

Currently Magit requires the user to explicitly choose whether to push to upstream (P u) or pushRemote (P p). There should be a single dwim command that intelligently picks between the two like how git push does it.

The reason this is bad is because the user may have muscle memory from pushing a branch that has no pushRemote, then accidentally pushing to upstream on a branch with pushRemote set, where pushing to upstream is a bad idea (like pushing a WIP feature branch to master).

Alternatively, there should be some way to prevent the user from accidentally pushing to upstream when pushRemote is set, like requiring a yes/no prompt.

Example for the latter: darkfeline@1e27996

[kyleam]

Alternatively, there should be some way to prevent the user from accidentally pushing to upstream when pushRemote is set, like requiring a yes/no prompt.

I like that idea, and on my end I'd probably enable confirmations (though for topic branches, I typically configure my upstream to a local branch, so there's no real risk of an accidental push).

There should be a single dwim command that intelligently picks between the two like how git push does

magit-push-to-remote and magit-push-implicitly call git push without a refspec. Perhaps you want to add one of those to your push transient?

[kyleam]

@tarsius I'm mostly staying out of this discussion at this point, but, given your workflow description, I want to clarify my initial response: the workflows you describe very closely align to mine. In all of those different scenarios, I too use magit-push-current-to-pushremote. Yet I still replied that I like the idea of adding (an optional) confirmation for magit-push-current-to-upstream when the push remote is configured.

It is because I have a setup where I nearly always push to configured the push remote that I want to guard against making a dumb mistake of pushing somewhere I didn't intend. As I mentioned in the original post, I currently side step this by setting the upstream of topic branches to a local branch (e.g., master or maint). However, for some repos, I would rather use origin/master or origin/maint, but I avoid doing so because I have write-access to origin and I don't want to risk an accidental push. (Obviously I don't find using local upstreams too inconvenient given I haven't tweaked my configuration to require confirmation.)

If I recall correctly, the above approach (using a local upstream) has only saved me from one accidental push, but I'm very glad it did.

[darkfeline]

I find it hard to follow you. Are you suggesting a particular new UI or are you saying the current UI is fine?

The point I and kyleam are making is that the current UI makes it easy to do a dangerous push for many average users (this isn't about your workflow tarsius, I understand you have an awesome workflow that doesn't have this issue). Users with simple centralized checkouts push with P u. Users with triangle workflows push with P p. Users with both will occasionally do a P u to disastrous effect, and the current UI does not prevent or warn against this.

[tarsius]

I don't oppose adding confirmation dialogues.

I have pushed a stub implementation to the confirm-push branch. The final implementation does not have to be based on that, but it should take the concerns/special-cases that I raise there into account. I find myself unable to push through and implement this myself at this point, so someone else will have to do the work.

It has been coming for a while, but I just went over the edge and have burned out. Effective immediately I am taking a mental health break lasting at least a month.

Kyle, sorry for dropping this on you like this. Please add the requested confirmation dialogues as you see fit and if you conclude that #4715 is an improvement, then please merge it. Likewise for other pull-requests that come up while I am gone.

[tarsius]

(Also look at ce5d2b3 from the idea branch. Maybe that is useful, maybe not.)

[kyleam]

It has been coming for a while, but I just went over the edge and have burned out.

Sorry to hear that. I hope the break gets you to a better (and long-lasting) state.