Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
A pull request to create pull requests #554
This PR adds a pull request creation flow.
I played with current code a bit and it works pretty well with typing in title/desc/target-branch ;)
What I'm not sure about is what's the expected first step for the pull request creation workflow in an editor: providing title/desc or reviewing the file changes first. The latter is the one I want to do first. We can probably create a tree view, similar to "Changes in Pull Request" and it contains file changes and commits. The description node for this tree view is now a pull request submit form where we type in necessary information for the pull request creation. Or we can use Quick Pick UI to do the submition work, like what this PR already implements. @queerviolet what do you think?
I think what we want to do long term is to immediately create a draft PR. Draft PRs are not pushed to the server—at least not publicly—but they otherwise have the same view as other PRs. We could either create another top-level section in the Github Pull Requests sidebar tree view (Drafts), or we could put them under Created By Me with badges that say Draft.
This way, you don't have to learn another interface, and we don't introduce another interface mode. You can edit the draft PR exaclty how you can edit any other PR you create, at a leisurely pace, and once you're ready, you can click a Publish PR button that publishes the PR.
I'm working on some mocks of this flow right now that we can discuss. Generally, it will require the following changes:
Since it's a bit more involved, I wanted to get this feature rolling first with absolutely minimal UX. The evolution I see is:
1 & 2 get us 90% of the way to where we need to be. With those two features in, you'll be able to create a [WIP] PR and edit it on the description page. The only thing you won't be able to do is preview a PR before sending it to the server. I think being able to do that is important in terms of building confidence—i.e., overcoming fear of submitting a PR that isn't quite perfect. But it doesn't really enable anything that you couldn't do before, provided you're willing to edit in public a bit.
So, in short: I agree, but think that should be a (near) future evolution of this feature.
So I've changed my mind. I don't think it's worth it to try for a version of this with a super-minimal UI. Common cases have too much state to work with before submitting, and asking a series of questions with the prompt UI is scary and unwieldy.
Consider a common case:
I think, ideally, we'll create a fork of the upstream and push our local branch there, and then create a branch against the fork. But that's a lot of magic to just "have happen". Ideally, I'd want the user to at least see what's going to happen on the PR description page before clicking Create PR, which means going ahead and creating that interface.
I'll post some of the mocks we used for UX testing, so we can discuss them. Also, I'm planning on saving draft PR information in git config settings, since we're already saving information there, and those can, it appears, hold arbitrary amounts of data.
You're right about this common workflow @queerviolet.
As of today, the way we handle PRs when you don't have push access is to have users create a Fork. This is a more complex flow that we should definitely open up another issue for it and have that be the next thing we tackle in this flow.
The basic flow for creating a PR is as such:
Do you want to open an issue to handle 7 in the above list better?