Hacker News Reader

Comment by sharp11 | Hacker News Reader

Lots of food for thought in this article, but the part I find most interesting is his distinction between "soft" and "hard" forks. (Viz., are you "forking" in order to collaborate or in order to go your own way?)

If collaborate, it would be nice to lower the barrier to participation ... more like Wikipedia. I know that I often don't bother to submit a PR for small changes bc of the overhead of setup. Whereas I fairly often make small edits to Wikipedia changes, because it's so easy.

View on HN

This is one of the few things that Launchpad got right. jquery, for example, would be at launchpad.net/jquery, and your own work would hang off of that. GitHub went with inverted namespaces (user/repo) instead, where every personal fork is an island unto itself, and the world is worse off for it.

I had hope that GitLab would take the opportunity to fix most of the problems GitHub introduced (or at least a few), but they seem to be interested in just copying the mistakes and chasing the market segment made up of people who's only criteria begins and ends with like GitHub, but on-prem.

GitHub at least has a simple way of making small changes: You can simply click 'Edit' on any file, which will make a fork, commit and pull request in one operation. It's only good for single-file changes you're confident to make in a simple web text editor, though. I've only used it for typos.

I don't like that doing so frequently litters your personal repository list with forks. Would be nicer if they allowed arbitrary users to push to branches like `incoming/<username>/<branchname>` in the original repo.

Isn't that up to the repository maintainer whether they allow pushes from other people? And sure, it litters your list with forks, but you can remove them as soon as the PR is merged. And that's the case for pretty much anything you contribute to (unless you can push there, of course).

No, there is no process in Github to allow everyone to push to a certain branch (or branches matching some regex). Github forces people without collaborator rights to use forks.

I've seen this lead to confusion where people fork a repo and send PRs even though they have contributor rights, because they didn't understand the difference. As an extreme example: https://github.com/flystack/misty/pull/101 - This is a repo with only one person with write access [1]. Yet this same person only commits to their private fork of this repo and sends himself PRs that he then immediately merges. I don't mean to blame the developer, only the Github UX.

[1] It says "6 contributors" on the mainpage of the repo, but four of these are from my team and we definitely don't have write access.

> Isn't that up to the repository maintainer whether they allow pushes from other people?

That's an orthogonal concern. What they're saying is what the essay suggests at the end, Github could maintain a list of "contributor refs" in the source repository in the same way they expose PR refs (refs/pull/*/head).

This could be managed entirely by the service provider (e.g. github) and invisible to the repository maintainer until a PR is created.

I don't know why Github does not make this easier. What I would like to do is:

    git clone https://github.com/mozilla/DeepSpeech
    [... edit & commit ...]
    git push # Github automatically creates and pushes to a branch called qznc/master
    [ one more click to open a pull request ]

All this assuming I have no write access to the repo and without creating a repo at https://github.com/qznc/DeepSpeech.

Absolutely. I've never understood the reason for requiring you to make a fork, just add my changes to the PR (in an anonymous branch for example) and be done with it! I don't want to 'fork' your repository to propose a spelling mistake fix.

Reply on news.ycombinator.com