Hacker News Reader

Comment by stonogo | Hacker News Reader

I know this is not a popular statement on Hacker News, but this development model existed for dozens of years before Github, and it will persist long after Github is gone.

The entire concept of a 'pull request' is a very recent fad, one with many drawbacks -- most of which have been enumerated by the very development teams you're insisting should adopt PRs. The largest single problem with PRs is the implication that we all have git repositories with a shared authentication mechanism. It's very difficult to enforce this sort of thing in a developer environment as diverse as these large projects have.

Sending patches via SMTP is arguably the most inclusive possible development model and I really value its availability in projects to which I contribute.

View on HN

> The largest single problem with PRs is the implication that we all have git repositories with a shared authentication mechanism. It's very difficult to enforce this sort of thing in a developer environment as diverse as these large projects have.

Why? Can't you just set up a GitLab instance and require that PRs should be submitted through that system?

> Sending patches via SMTP is arguably the most inclusive possible development model and I really value its availability in projects to which I contribute.

So just keep that option available for those who want it. Set up a bot that opens PRs automatically for any patches it receives by email. Doesn't seem like that'd be terribly difficult.

Not terribly difficult to describe, sure.

GitLab has a well documented API: https://docs.gitlab.com/ee/api/merge_requests.html#create-mr

You could probably do the whole thing with like 50-80 lines of bash.

That is a great idea. If we need to add features to GitLab to do this please let us know.

GitLab already has a built-in way to reply to comments by email, right? I wonder how difficult it'd be to make "submit PR by email" part of GitLab itself.

Personally I probably wouldn't use that feature, as I'm already very comfortable with the Web UI, but judging from some of the other comments in this thread it sounds like some people might...

Submit patch by email to create MR is a feature I think we're open to if people indicate they would actually use it. I have the feeling that if we would that the kernel maintainers still wouldn't use it. But I'll gladly be proven wrong.

I can't believe the CEO of Gitlab has time to read all these threads. Do you use an HN bot yourself to see Gitlab mentions?

I must admit I read HN quite a lot :/

I found out about GitLab via Hacker News and the company got started after the kind reaction to https://news.ycombinator.com/item?id=4428278

We also have a "mentions-of-gitlab" channel in our chat that will alert us of any mentions of GitLab on any major place in the internet.

I'm ignoring that for now because it is overwhelming. Luckily we have a team of community advocates who respond to that.

> Why? Can't you just set up a GitLab instance and require that PRs should be submitted through that system?

This requires the contributor to have (yet another) account. Requiring that account to be on your gitlab installation isn't particularly better than requiring that account to be on Github.com.

> So just keep that option available for those who want it. Set up a bot that opens PRs automatically for any patches it receives by email. Doesn't seem like that'd be terribly difficult.

What would they be pulling from, exactly? When you send a patch, you're just sending the changed code. There's no 'other repo' to pull from. I suppose you could allow the system to create dedicated branches for incoming email, and then the PR could come from that branch, but this is computationally expensive (possibly ruinous, depending on the complexity of the repository and the size of the diff), and could easily be abused by sending boatloads of spurious diffs.

Introducing this web interface requirement simply takes way more engineering than people assume, and even suggesting it presupposes the existing system doesn't work (it does) and that there is some inherent superiority about using a web interface to do the job (there isn't).

> This requires the contributor to have (yet another) account.

That's true, but I'd say the amount of time involved in setting up a GitHub/GitLab account is pretty insignificant. Probably comparable to the amount it takes to subscribe to a mailing list.

> What would they be pulling from, exactly?

Have the script dump the code onto a new repo or branch and pull from that.

> but this is computationally expensive (possibly ruinous, depending on the complexity of the repository and the size of the diff)

Huh? A branch in git is literally just one file on the disk, and the diff has to be downloaded anyway regardless of whether you're sending it by email or by PR.

> and that there is some inherent superiority about using a web interface to do the job (there isn't)

There is: it's more user-friendly, and thus makes it easier for people to contribute to your project. When the success of a project depends on people being willing to devote their free time to work on it, it's important to make that experience as frictionless as possible.

> That's true, but I'd say the amount of time involved in setting up a GitHub/GitLab account is pretty insignificant. Probably comparable to the amount it takes to subscribe to a mailing list.

Yes, and now you have yet another remote internet account to manage, to worry about platform compromises, your government commandeering, etc etc. And you don't necessarily have to subscribe to a mailing list to send mail to it.

> Huh? A branch in git is literally just one file on the disk, and the diff has to be downloaded anyway regardless of whether you're sending it by email or by PR.

I host large git repositories. Creating and managing that file is not computationally trivial on an extremely large and extremely active repository.

> There is: it's more user-friendly, and thus makes it easier for people to contribute to your project. When the success of a project depends on people being willing to devote their free time to work on it, it's important to make that experience as frictionless as possible.

It might be more user-friendly _to you_, but to someone whose internet connection is a 2G GPRS connection, on a computer whose operation comprises a significant portion of the user's monthly power budget, email is infinitely more user friendly than a web app. Your speculation regarding its essentiality to the success of the project is a little off-target, considering we're discussing the kernel of the operating system that runs on the majority of mobile devices, servers, and supercomputers worldwide ... and it doesn't do pull requests.

Do you run a GitLab instance? It requires someone to maintain this. What if the server goes down?

If you're unwilling to invest the time host it yourself, you can always use GitHub or GitLab.com instead. Hosting your own instance is only important if you're the type who wants to have full control of the server hosting your repositories.

It's only the most inclusive possible development model if you narrowly define "inclusive" as "least technical friction for contribution".

Most people have a different notion of what inclusivity means, most notably having a welcoming UX with clear rubrics for contributions so that contributions have the best chance of actually being accepted.

When people complain about something being difficult for humans, promoting something that's easier on a technical level is turning a deaf ear.

No, I mean inclusive, because it does not require the contributor to identify in any way, it does not require the user to have mastered the UX du jour, and it does not require the user to even have a full copy of the git repository.

All you have to do is send your code, on whatever device you want, using open, standardized protocols.

I consider myself a git novice, so please explain if I am wrong. But isn't a Pull Request basically: "I cloned your project and made a bunch of new commits, please pull from [url to repo with .git folder in it] to merge those changes in to your project"?

Yeah, that's exactly what it is. Most Web UIs that implement pull requests though only support Pull Requests between repositories hosted on their platform. You can't just provide a url to an arbitrary git repo to pull from. In principle though, there's no reason they _couldn't_ implement a feature which would allow that.

Contributing by patches is even simpler, since you don't even need a place to host your repo. Instead you literally do "git format-patch some_base_ref" and get a bunch of files you mail someone.

It doesn't get any simpler...

Reply on news.ycombinator.com