discussion about git pr push -r -n and defaults

[bast]

How do you typically use git pr push? Are you using -r -n always or only sometimes?

I think the default should be what we do most of the time but unsure what we do most of the time? I can imagine myself typing -r -n always.

These are not too easy to remember. What is -r short for?

[rkdarst]

That's a good question tied up in history, and could be improved now: At first, there was just 'push' which didn't do anything fancy other than push to the right remote. Then I got tired of going to the web browser to open them, so added "-r" which means "open a pull Request automatically" It calls the "gh" subcommand to do this (but gitlab *has* to open them at the same time it pushes...) Then I got tired of saving and closing the editor, so added "-n". These days I almost always use "-r", and then very often "-n" too. I've actually made it shorter, adding a git alias `prpnr = "pr push -n -r`. Then I added bash aliases for "m" (git pr master; detect and check out master branch), "prn" (git pr pr new), and "prpnr" (git pr push -n -r) so I can even avoid typing "git". So I've gone down some deep hole here, probably too deep to be default. This should probably be re-thought some, because indeed it is a bit much and my solution is too esoteric. How do you think it should be designed?

[bast]

For me I anticipate that I will use git pr for the "smaller" PRs where I don't want an extra step on the web. For elaborate PRs where I need to very carefully prepare a PR description based on a number of commits, with cross-references to issues etc, I might go via web.

This means that I would probably prefer git pr push to always open it and rather have a flag that does not open it. But git pr push perhaps does not convey that it does more than pushing. I was thinking about git pr open? But does that convey to the user that something is pushed?

Of course I can solve this with an alias but wanted to discuss good defaults before this tool goes viral and it becomes harder to change defaults.

[bast]

The more I think about it the more I like git pr open. It opens a PR. Does not matter how it does it, by pushing and stuff. All I want is that it opens the PR for me and I can move on.

[bast]

But if git pr open exists, can it be confused with git pr new? ("new pull request?")

If I did not know what git branch does I would consider renaming git pr new to git pr branch.

[rkdarst]

I like "branch" and "open" (and it's easy to keep backwards compatibility). "pr open" can directly call 'push -r", the script invokes itself other places, too. "pr branch" makes sense as the new name of "pr new", though we avoid confusion since "git branch" just makes branch and "checkout -b" checks it out. I think this won't be a big deal.

[bast]

The new checkout -b is switch --create so we could also consider git pr create but that again might sound like creating a pull request. git pr switch? git pr switch --create is too long.

[rkdarst]

I think "branch" is a pretty good name. As a verb is is describing what it does. One reason for "push" not using "-r" by default: I also sometimes/often update a pull request by just "pr push". For bigger changes, this is more often than opening. So, add "branch" and "open" ? Or think more about switch/create?

[bast]

Sounds good:

• git pr branch instead of git pr new
• keep git pr push which does not do -r by default (still I find -r non-intuitive character)
• git pr open is porcelain for git pr -r (how about -n?)

[rkdarst]

The -n came from --no-edit in the hub Github API interface, and
seems to be an invention of mine.

What about push -o for "push and open", to be consistent with the new open? (-n also works, though) ? (-r was "Request it in addition to push").

Here is the reference for hub:
https://hub.github.com/hub-pull-request.1.html
And should also avoid clashing with the new cli:
https://cli.github.com/manual/gh_pr_create
Neither -o nor -n are taken in either, so it's OK to use either. -r is already taken.

[bast]

I like git pr push -o instead of git pr push -r.

And -n is intuitive but should it not be default and we rather have git pr open -e|--edit to open the editor once more?

[bast]

And although commands can reference each other and backwards compatibility is "no problem", I would still limit the option to not arrive at something like Git where there are some options where I ask myself whether Linus has used them twice and now we are stuck with them.

So perhaps instead:

$ git pr push mybranch
$ git pr push -o mybranch

we could do:

$ git pr push mybranch  # here the user preferred to not open yet
$ git pr open mybranch

[rkdarst]

I still sort of like the principle of least surprise: it's safe to open the editor (pre-filled with the message it would have). But not doing that could result in spam to projects when someone doesn't realize it will immediately open it and mail everyone.

we could do:
$ git pr push mybranch
$ git pr open mybranch

In fact that's sort of how this evolved: there was git pr push (push) and git pr gh (to open the pull request itself on Github). I wanted even fewer keystrokes, so added -r, then stopped using gh I think keeping the things separate in the "base case" is a good idea.

To make it worse, Gitlab has different semantics:
https://docs.gitlab.com/ee/user/project/push_options.html
The way you open it is git push --push-option=merge_request.create, so it has to be a part of push somehow.

Should we have a video chat to talk about it? I feel this is going on quite a while, and more quick discussions=better.

[rkdarst]

The branch one seems simple so I did that one first.

[bast]

Good convincing argument to not make -n default. Yes we can talk over video if there is something to discuss about the GitLab part. And I highly recommend to limit the number of options and aliases and not to keep any undocumented ones. I expect that this will hurt in future. We can talk about it over video.