Github Pull Requests

moshe weitzman's picture

For code contributors and reviewers, I think the Github Pull Request model is extremely tight. Please read their blog post at Note that Github can optionally associate an issue with a Pull request. I think thats a good starting point for how pull requests and issues play together.



marvil07's picture

Yep, we really want to implement the things behind to actually have the ability to use pull request in git phase 3, and like you mentioned, github is a good example of how it can works.

We need to figure out how exactly it should/can work for our issue's model, but we want to have it! ;-)

Yep, there's a lot that

sdboyer's picture

Yep, there's a lot that they've done that we can work with/from. There are some key differences, but that post especially does highlight most of the principles we're going for. Biggest distinction is that Github's pull requests are a restricted/confined conversation to people who have push access to the requesting branch, whereas our conversations are open.

Are you sure about that?

Zach Harkey's picture

Biggest distinction is that Github's pull requests are a restricted/confined conversation to people who have push access to the requesting branch, whereas our conversations are open.

Are you sure about that? I just submitted a pull request to the oocss project without having push access and I couldn't believe how smooth and intuitive the process was.

Here is the documentation I followed.

All you have to do is

  1. Fork the project you want to contribute to.
  2. Clone a working copy and create a topic branch.
  3. Commit and push your changes to the feature branch on your fork.
  4. On the GitHub project page for your fork, switch to your feature branch.
  5. Submit a pull request to the parent repository from your topic branch

Your pull request immediately spawns a discussion where all comments, code reviews and followup activity are captured chronologically as they happen.

So in my case when I was notified by email that someone commented to say that I could remove another redundant css selector, I committed the additional changes to my topic branch and the pull request discussion was automatically updated with this activity.

Github's workflow is so smooth and intuitive that it really promotes collaboration.

Yes, I'm quite sure. I think

sdboyer's picture

Yes, I'm quite sure. I think you missed my point: it's easy for you to open a pull request. What's not easy is for me to contribute code to the pull request you opened. I can harp on that comment, just like someone did to you, but I can't actually fix it myself, commit the fix & push it somewhere, and have my fix directly interwoven into the pull request.

As far as I'm concerned, Github's done just about the best conceivable job when it comes to facilitating that 1:1 interaction. But it gets awkward fast if you want to actually let multiple people write code together - you have to actually spin up a new repo for that. And if you both already have forks...yeah.

Maybe that's an edge case - but of the last three or four patches I've reviewed, I've really wanted to be able to make tweaks and push them back up into the conversation on top of what the other person has already done. Can't do it with Github, and unless I'm missing something big about how their system is structured, it runs counter to the fundamental structure of their interaction dynamic. We don't have to be limited by that on d.o, so I'd rather not.

AccessGranted! service

moshe weitzman's picture

One plausible solution is to build a simple service on top of Github. Let's call the new service 'AccessGranted!'. The flow goes like this.

  1. User1 starts a "patch" by forking a Drupal project on Github.
  2. User1 submits a PR to the maintainer
  3. If User1 accepts helpers, she adds the 'AccessGranted!' user as an Admin on her repo
  4. If User2 wants to add commits to the PR, he requests access using a Dreditor-ish button on the PR or by visiting AccessGranted!.com. AccessGranted! is a nice bot and always grants access to the target repo. Now, both Users can collaborate on the PR, using Github's world class code review system.

Github doesn't have

pwolanin's picture

Github doesn't have branch-level access control, as far as I know, so you'd have to delete the fork to make a new patch with different people having access?

Frankly, other than the UI tools, a lot of the github workflow is quite limiting, so I'd tend to agree with Sam.

Looks like you are replying

moshe weitzman's picture

Looks like you are replying to my post above.

Why not just keep adding contributors to the same repo? Do you really need to exclude people on a branch by branch basis. It is not like you can do that on