[colbyrussell]

"Easy" like:

    git diff master..bugfix > bugfix.patch # or `format-patch`
    # now attach/upload bugfix.patch

Instead of:

    # make sure you click around github.com to create third fork
    git remote add unnecessary-third-fork $THIRDFORK
    git push unnecessary-third-fork bugfix
    firefox $THIRDFORK # now click around to file a PR
    # now wait for your PR to be merged
    # now click around on github.com to delete $THIRDFORK
    # ... unless you just leave things laying around

What makes the second sequence easier than the first?

[kelnos]

In the "easy" path, you're neglecting the lack of standardization in the "attach/upload" step. For some projects it might be as simple as "create an account on their bug tracker and open a new bug and attach the patch", but for others it might be "dig through their website to find a mailing list, dig more to figure out how to subscribe to that mailing list, send email". and then you might: "get a bounce because the patch is too large", or have to "repost because your mailer posted the patch in-line instead of an attachment, which corrupted it", or...

As much as I hate centralization, especially when the central entity is a for-profit corporation running closed software, often that ends up giving you a standardized experience that makes things easier. "Easier" doesn't have to mean fewer steps; I agree that the GitHub workflow you describe isn't simpler, but if you've done it a few times, it's mechanical and you don't need to think about it. GH even provides a command-line tool[0] that lets you avoid most of the click-around-on-website steps.

[0] https://github.com/github/hub

[colbyrussell]

I agree with some of what you say—one caveat is that you're still on the hook, for example, for finding out which GitHub URL/repo maps to the project you want to contribute to. In practice, this is roughly on par with the difficulty of finding the link to the self-hosted Bugzilla instance. It's a shame that decentralized single sign-on is still such a disaster, since that's essentially the one thing that GitHub has as a leg up over other options—assuming you've contributed to some other GitHub project before.

To stray outside the lines with some meta-commentary: it's nice to get a well thought out response instead of the sort of kneejerk rooting-for-my-home team that's on display in the wasteland of intellectual dishonesty in the comments below.

[tracker1]

I'm not sure it's the same... when I search for issues and contributions... I almost always google for github projectname etc. When it's in GH, usually it's easy enough (unless issues are closed because they're managed with a different repo).

For the most part it's the same workflow. Also, if it's a trivial change (like fixing/appending something in documentation) you don't even need to leave the browser.

Discovery is another issue... it's far more easy to use Github semi-socially than most other platforms. Something I both love and hate is that GH doesn't have a direct message functionality. On the one hand, I wouldn't want to be bothered with a ton of end user emails for the same issues over and over... on another, after you've waited a week for a bug fixing PR, it's not fun either.

[BinaryIdiot]

The majority of git users I know don't know how to create or apply a patch. The few that do only do so in the odd FOSS project that requires it.

Whereas when using Github you click a button, get your own copy, do whatever you want to it, and then click a button to open a pull request. You _tried_ to make it look like using GitHub.com is somehow... complicated. But it's dead simple and you even added steps, like "waiting for PR to merge" etc that is the same with a mailing list anyway.

I get it. You might like the mailing list better to avoid a single company handling all of the OSS contributions. But let's not ignore the actual good aspects of github by making up stuff. If you want to convince people to _not_ use github it's going to take more than this.

[rocqua]

The attach and upload part, and figuring out how the discussion went on the mailing list if changes are requested.

[colbyrussell]

What makes either of those things harder than what you have to do to use github.com?

[chinhodado]

If you have never contributed to a project before, the "attach patch and upload/send mail" part is a significant hurdle. You have to figure out which mailing list to use, which is not always easy to find, then find out the person/group to address it to. That alone already discouraged many people from even bother.

[jyrkesh]

It's hard when you have lots of folks jumping into a code review, and you don't want to duplicate effort or you want to rapidly iterate on your code.

You know those email chains that just continue to fork? Where people reply to the original (or the first couple replies) with their wall of text after a couple other replies have already trickled through?

That's what a collaborative, stateful PR solves.

[colbyrussell]

Everyone is trying to get me to defend mailing lists. I have no idea why. I haven't said anything about them. In fact, I hate mailing lists.

[chinhodado]

> I haven't said anything about them.

> # now attach/upload bugfix.patch

Where do you "attach" your patch file?

Also, if it's not GitHub/GitLab/gerrit/reviewboard/etc. and not mailing list, what other workflow for code contribution are you talking about then?

[dblock]

I used patches and lists before, a lot. It was either hard or impossible to track more than one at a time, in context and with lots of conversations around specific lines of code. It was also a nightmare for maintainers to constantly want to tell people to rebase their patches based on other people's patches. To link patches to other patches to issues, etcetera.

The Github website and its fork/pull request flow has increased my productivity and the amount of things I contribute to or can maintain with some level of sanity 100x easily.

[kazinator]

Patches sucked, so Torvalds switched to BitKeeper and then wrote Git.

If my project uses Git, I can easily accept a patch. If someone happens to give me a patch against some old version that doesn't apply to HEAD, I can just "git reset --hard" the HEAD that version, apply the patch, and then rebase with "git rebase".

I would expect most people to be making patches out of their own git repo (using "git format-patch") anyway; they should be able to rebase first.

[y2kenny]

Gerrit would be simpler. You would just do `git push origin HEAD:refs/for/<branch>`. And I would argue the "now attach/upload bugfix.patch" is as unnecessary and time consuming as the remote/fork branch mechanics that the PR workflow requires (not sure why you didn't include the git send-email/specify email address part.) Gerrit review flow is much simpler than both.

[Cyph0n]

I agree that the initial review creation process is a bit complex with the GitHub flow. But most of the time, you end up needing to make changes to your diff based on review comments, etc.

Then there is hooking up PRs to your automation setup.

This is where the GitHub approach shines imo.

[vngzs]

GitHub could support this workflow - they would need to find a way to integrate patches into GitHub Pull Requests.

One way to do it would be an "upload patch" option on others' repositories, where GitHub forks the repository for you under the hood, possibly creates a branch for you, and applies your patches linearly to that branch. It opens a pull request to the targeted branch of the upstream repository from your branch. Then when the pull request is closed, it cleans things up for you (temporary branch, fork) under the hood, if desired.

[kochthesecond]

github/gitlab is a good place to browse the code. What better place to have a single click to create the fork you need?

And you do need that fork. If you want any kind of CI/CD stuff on the repo you sort of need to pull the changes in from a third party source to make sure nothing bad will happen.

now try to keep your patches up to date with constant rebases and comments from reviewers. Maybe some parts are ok, but some are not so you go back and forth for a couple of weeks. Fewer people will want to go through this extra hassle that they don't even get paid for.

[CameronNemo]

FWIW there is a CLI tool for interacting with GitHub.

https://github.com/github/hub

And I do just leave forks and branches laying around :/

[simias]

You ignore the most important part of the workflow, the patch review and the iterations that you'll probably have to do on it. If you just send your patches to random mailing lists and never bother to follow up on them then yeah, that's pretty easy.

I like "old tech". I use emacs, my mailer is mutt, I don't like HTML email, I like IRC, I like using a terminal, I don't like how the web is eating everything.

Still, my experience using mailing lists is just garbage.

Random anecdotes from working with project using mailing lists for patch reviews:

- I find a patchset that seems interesting, but I wasn't subscribed to the ML back when it was posted. Now I need to dig up the mails on some archive out there. I want to see if there were important comments/revisions on these patches? Well here goes 30 minutes of clicking on "next by thread" to sift through the entire discussion, hoping not to miss anything.

- Every project has slightly different guidelines for contributing. Should I put somebody in copy? Run some script on the patch beforehand? Is there a special procedure for contributing patches? Here comes 15 minutes sifting through the "contributing" doc to figure out the modus operandi. I still get it wrong from time to time on projects I don't frequently contribute to (mainly because I get confused between different projects and forget the idiosyncrasies). And of course you need to figure out the exact mailing list to use, whether you need to subscribe to post on it etc...

- You get some feedback on your patch and need to create a new revision? Oh boy, that's where the fun begins. Don't forget to set the "--in-reply-to=" to your git command line if you want your patches to thread correctly! Also some projects prefer that you add a revision number to your patch set, but I actually forgot how to do that and a quick browse through git format-patch's man page didn't help me. Boy, this sure is easy and straightforward! To think of those losers on GH who just have to push their updated commits on their branches and the PR is automatically updated.

- Okay now you've amended your patchset and integrated your modifications. But the patchset is large and the modifications are mainly small coding style issues. Do I send the patch right now, at the risk of getting comments on two separate threads, one outdated, and also risking spamming the mailing list if I do other modifications in a row? Wouldn't it be better buffering the changes and pushing a big new patchset later once I get more feedback? But then the other reviewers will work with outdated code... Wow, it sure does feel like the proper tool to work with! I'm so glad I'm not using github's PR system right now.

I can't justify this. I'll defend IRC over Slack/Discord to the bitter end, mutt over gmail, Emacs over VS Code but I just can't comprehend how mailing lists are still a thing, much less patch mailing lists. I actually have some modifications to software that I use that I didn't bother upstreaming because I can't be arsed to figure out where those patches need to be sent and how. On the other hand I have already submitted PRs for small, non-important one line changes on github because it's so simple and frictionless.

I want mailing lists to die. I want patch mailing lists to die a painful death.

[joshuamorton]

Now how does CI work with that first workflow?

[pas]

in case of the linux kernel, there are bots that lurk on lists and then sometimes they send you a mail if they found a bug running whatever arcane test suite on your code.

so, in general, it works like shit, but some people are not willing to accept this, because "it works for me".

[SEJeff]

You can create a pr with the open source "hub" tool with a single command.

[colbyrussell]

I only counted opening a pull request as a single operation to begin with.

[diminoten]

Are you honestly taking the position that graphical user interfaces are harder to use than CLI?

[colbyrussell]

Let me ask, do you think that the content of my message reduces to "graphical user interfaces are harder to use than CLI"?

[diminoten]

Yes, I do!

[colbyrussell]

Please explain how you got there, because I'm at a loss. Both examples involve using the CLI. The GitHub version I ran through actually includes more CLI steps. How could that possibly have been my intention?

[diminoten]

Your references to clicking repeatedly, and the general fact that github.com's innovation is the GUI it puts on top of a git workflow.

[colbyrussell]

I'm mystified about what's going on right now.

Both versions involve clicking.

Both versions involve command-line steps.

The difference is that the GitHub version requires more of both, needlessly. That's the point of what I wrote. That's the only point.

I don't understand this context where I'm being forced to defend an argument that's been foisted upon me and that I never made and never even thought of trying to make.