Idiomdrottning’s homepage

The diminishing inconveniences of contributing to GitHub projects

Y’all know I hate GitHub, including the amount of hoop jumping needed to contribute to projects hosted on there.

The gh cli app fixes that.

After having set it up it’s as easy to contribute to GitHub-hosted projects as it is to use more normal git repos that accept send-email.

I have a shell script that I can run in any cloned github repo where I’ve made changes; the script then checks if head is detached, asks me if I’m happy with the current branch name or prompts me for a replacement, commits everything, and then calls gh pr create --fill which in turn automatically does all that fiddly web stuff I was complaining about above: creating the fork if there already isn’t one, pushes it, and opens a pull request. Or if I’ve already committed my changes locally I can still call gh pr create --fill (or without the flag if I feel like writing pull request text).

So from a convenience level I can’t complain about GitHub anymore. The political argument remains: shouldn’t we as coders own our means of production? It’s bonkers that contributing to projects requires a Microsoft account.

I used to read a blog that argued for how home cooking was cheaper, easier, and faster than store-bought readymades. Cheaper and healthier, sure, but it was a bit disingenuous that he counted the time spent “going to the store, being at the store, deciding what to buy, buying it, going home” for the ready mades but never for the home cooked meals.

Similarly, I can’t in good faith argue the convenience argument with GitHub now that their dumb li’l app has made it slightly less painful to automate forking and pull-request creation.

The underlying complexity argument also remains: GitHub is way more complicated to understand conceptually than non-GitHub git, in addition to being so different that it makes vanilla non-GitHub git seemingly hard to grok if the GitHub version was your first exposure. But that complexity argument is just a grokkability obstacle and now no longer a practical usability obstacle. For those that have been forced to created GitHub accounts, that is.

I’m going to stick to avoiding GitHub for my own projects.

Of course, for the poor sucker who is going to have to deal with all those incoming pull requests, that’s another thing entirely. On that side of the equation, the convenience argument is alive and well.

Old post (from October of 2022)

Over the last year or so, I’ve used the li’l “pencil icon” on GitHub to make changes directly in the web interface many times, and then following their wizard all the way to automatically making GitHub’s twisted version of a “pull request”. (Make sure to not have “hide email” on in your settings if you do this or your contributions will get obfuscated.)

I’ve sometimes felt a bit guilty. I rag on GitHub all the time, I hate it, I don’t have a forge up on my own site—but they have a feature that I’ve used so many times for small contributions! If that pencil is so darn good—shouldn’t I provide a similar feature or even move my stuff over to GitHub?

But as I thought about it a li’l more, I sobered up and realized that the pencil itself is more of a mitigation for how bad GitHub is, than a baseline good.

To make changes on GitHub projects without the pencil, it’s…

  1. Make a fork using the web interface.
  2. Make a branch using the web interface.
  3. git clone -b my-new-branch-name https://my-fork-repo-url.git
  4. Run git branch to see that I’m in the new branch.
  5. Make changes (or paste them in if I accidentally already have my own local version)
  6. git add the files
  7. git commit with a good message
  8. git push
  9. Go back to the web interface and try to remember how to make pull requests.

Compared to a normal, non-GitHub repo where it’s just easier to git send-email or git request-pull.It works for GitHub-hosted repos too, if I believe they’re gonna be cool with normal patch mail or normal requests to pull.

With the pencil method, I still need to:

  1. Find the right file and location, without my familiar and beloved grepping or source browsing tools
  2. Make edits with their crappy web editor or paste them in from a real one
  3. Not be able to test, compile etc (unless I also did the same change on a local copy), so it’s mostly usable for documentation changes

The pencil is smoother and simpler than the long-way-around for GitHub, but it’s just not as smooth as being able to use and contribute from my own local copy directly, the way I can with git send-email. Especially with straight for Emacs making things so easy since it hooks up my local repo directly with describe-function and friends.

That’s not to say that I’d never wanna add a similar “web-editing” feature to my own stack as an alternate way to contribute, but first and foremost I’m glad I support the primary workflow, which is people using git or git clients and real editors instead of browsers.

TL;DR: Sandra hates the web, news at eleven