Hacker News Reader

Comment by informatimago | Hacker News Reader

I was about to clone it and push a patch. But then, I realized how complex the procedure was going to be:

1- clone the repo on github 2- clone the clone locally 3- patch the file 4- commit (with a meaningful commit message) 5- push the patch to the clone on github 6- go to the github web to post a pull request.

Plus, that would leave a trace on my github account (I assume that I could:

7- delete my github clone.

but only after the pull request is acted upon (which even if automatic is bound to take some time during which this github activity could be seen).

The lesson here is that providing small patches is too costly.

View on HN

You don't need to actively clone a repo to make a change. You just click "Edit" on the file you wan't to change and it'll do the heavy lifting for you.

True, you still have to make a commit message and click submit on the pull request, but the cloning/forking is taken care of behind the scene

If anyone hasn't seen this yet, checkout https://github.com/github/hub to do everything you'd do at Github on the command line (pull requests, forks etc). I use it and it's awesome!

If you view the file on github.com, you should see an edit button, which - I believe - makes the whole process a lot simpler.

The GitHub pull request model is absurdly complex for drive-by changes. I wish there were a way to just send a patch.

The edit button lets you change it easily

Obviously this doesn't apply here, but how does that work with changes across multiple files? Even one-off changes sometimes need to touch different parts of the codebase.

The ideal workflow for me would be:

1. Clone the repo locally (not making a public fork that requires cleanup).

2. Make changes and commit them (not making a branch that requires cleanup).

3. Send the patch (or patches) for review.

4. If the patch is reviewed, it's either automatically landed or a project committer applies it and commits it. Either way, there's nothing else I have to do at this point besides deleting my local clone.

I can see how the GitHub model works for people who contribute to the same projects frequently, but there's too much stuff you have to do (forking, cloning, branching) and then un-do if you're making a drive-by change and don't want the project to clutter up your profile.

Why are you fixating on this notion of cleanup? There's no need to "clean up" your public repos.

Even if you're making complex changes, I think GitHub is much easier to work with than the classic "patch" emails.

I frequently will randomly fork a project that I'm using and submit a minor pull request when I wouldn't hunt down their source control system, clone it locally, make changes, find their preferred email/patch system, look up the commands to create a patch file, and email the patch.

GitHub is drop dead simple:

1. Click fork. 2. Edit your fork online or clone locally, committing changes. 3. Click the "pull request" button.

Just because a model is new doesn't mean it's worse.

https://github.com/sociomantic/git-hub to the rescue!

Reply on news.ycombinator.com