GitHub pull requests are too heavyweight 2

New version of an old rant. The GitHub pull request model makes sense if you plan to submit one giant PR a week. It’s terrible for rapid collaboration. Today I wanted to submit a 5 line patch to openaddresses/machine, in the branch ditch-node. I already have a fork NelsonMinar/machine. I had to:

  1. Switch to master branch in my clone of NelsonMinar/machine
  2. In my clone, manually set up an upstream remote for master
  3. Pull changes from upstream merge them with a fast forard.
  4. Push the merge result back to GitHub
  5. Repeat steps 1-4 manually for the ditch-node branch. I guess you’re expected to do this manually for every branch you care about.
  6. Create a new branch in my clone. I branched off the ditch-node branch
  7. Make my changes and commit them.
  8. Push my new branch back to GitHub with “–set-upstream origin”
  9. Use the GitHub UI to create a pull request.
  10. Fix the pull request so it’s a diff against ditch-node, not master. Note the branch I’m creating the PR in was branched off of ditch-node; no idea why GitHub didn’t respect that.
  11. Submit the pull request. Never ever touch that branch again until it’s accepted.
  12. As a bonus, the project maintainer warns me he has to rebase my pull request so it’s going to break my fork until I update.

It’s too much work on GitHub to follow along some repo and make occasional friendly improvements to it. I could use some simplified workflow which is just “keep my forked repo updated at all times with upstream unless it would clobber some work I did”. I imagine I could write a script to do that.

Maybe GitHub expects frequent committers to have write access and not go through pull requests. I like the review and auditing of pull requests, though.

Update: John Firebaugh recommends git-up and git hub to help make this better.

3 thoughts on “GitHub pull requests are too heavyweight 2

  1. I use github at work with pull requests but within a single repo, and it’s not bad: create a branch, do the changes I want, push the branch, submit a pull request. Of course, that depends on having write access to the repo (because the pull request requires creating a new branch), but I wonder: maybe you could get a similar workflow by creating a throwaway fork instead of reusing a long-lived fork as you do? Of course, if the commits you want to merge in originated on your long-lived fork then there’s the question of how to get them over to the throwaway fork, so you’d have to do some git diff | patch -p1 fun, and there’s a whole extra clone which could be a pain for a large repo, but it seems a lot more pleasant than what you describe.

Comments are closed.