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?
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.
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.
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.
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.
Can't reply to the sibling, so replying here. Mozilla used to work that way (upload patch to Bugzilla), but it was so cumbersome they switched to Phabricator.
> Please actually point out how the GitHub workflow can be even more simplified than what I outlined above
Adding a remote is generally a one-time cost and is unneeded for every PR, so adding that command (along with all the associated comments) makes it appear more complicated. The reality for most GitHub users is that they simply have to do:
You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows.
> Adding a remote is generally a one-time cost
It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to.
> You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows.
Having to create a fork per PR is a rather antiquated way of doing it. In my experience, you can almost always push to origin and create a new PR from the branch, but maybe I've just been lucky with the projects I contribute to.
> It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to.
It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay both N times, where N is the number of projects you contribute to.
Why am I having to repeat myself here? You can never push to origin unless it's your own project or your team's project.
> It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay [...] N times, where N is the number of projects you contribute to.
Buddy, the entire premise here is user "Monotonic" telling me that configuring remotes is unnecessary and that that in fact he or she just pushes to origin.
They are referring to origin as the forked repository. E.g. if I contribute to nixpkgs (the NixOS package repository), I only have to fork it once, use that as my origin, and can create branches and submit PRs.
So, you are both right. If you contribute many times to the same repo, you only have to fork once. If you do a lot of drive-by contributions, you'll end up forking a lot of repositories.
(I fully agree that GitHub has a lot of overhead compared to git format-patch/diff. GitHub et al. also have some benefits in terms of communication. At any rate, diff/format-patch are not that hard, so I think any git user should learn it.)
On the drive-bys... create a YOURNAME-contrib organization, that you can fork to. I've started down this path which will help more as I get used to it.
> If you contribute many times to the same repo, you only have to fork once. If you do a lot of drive-by contributions, you'll end up forking a lot of repositories.
That doesn't contradict anything I've written here, or anything I've written in years past on exactly this topic. But this _entire_ branch of conversation started with someone quibbling that I didn't rank configuration of remotes as a zero-cost operation. So, no, we're not both right.
Right, you set origin to the branch you own, and upstream to the original project. Then `git push origin foo` works, and you can get a URL printed directly on commandline to start the PR flow.
I agree it's a cost per repo you contribute to. However, you can also do it reasonably cheaply with scripts. I recall you have to use hub in addition to git commandline, but once you get it set up then it's basically zero extra commands if you bake it into a clone. Run a script that does the fork to your github username and clone to your local box, do your normal modifications and commits, then git push origin and click on the URL to get dropped into the upstream PR workflow.
That's surely equivalently complicated as adding a second remote.
Almost every pull request I've made to a project on GitHub has started with a "git clone http://github.com/example/example.git", since they start with bringing down the source code and finding the bug in the project. Sometimes it's something I can fix, so I then need to fork the project on GitHub, add a remote (or replace origin with my fork's location), and make the commits.
That's not too difficult, but it's not easier than sending a diff to a mailing list. If any discussion is necessary, it's easier to keep track of that on GitHub. It's also much easier to see the patch 3 years later, if the maintainer wasn't interested — that's the big feature which makes GitHub (or its competitors) worthwhile to me.
(A long time ago I sent a patch to Git itself to the Git mailing list, and it was about 6 months before it was applied. However, it was applied, so they must have had some way of keeping track.)
I'm going to try to make this as straightforward as possible: Where in this[1] comment does an error lie? Please make a copy and edit it to reflect what you're saying here and then show me the result.
I'm going to skip ahead here. You're going to replace the `add unnecessary-third-fork` command with `set-url origin $THIRDFORK`. Either that, or you swap for a `git clone $THIRDFORK` so "origin" is set as a result of the clone.
How many steps do you need to eliminate before you can match the cost first sequence (2 steps)? How many steps does your advice eliminate? What are the total number of steps involved in the GitHub approach? I'll wait for your answer this time.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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".
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?
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.
What? You get to imagine some bad argument that would make it most convenient for you, and then demand that I defend that argument, as if it were one that I wanted to make? This is what I'm responsible for? Dealing with someone who resorts to strawmanning the person/idea at the other end when challenged?
It's not a direct consequence of anything that was said. It's a possible implication - in the conversational sense of implication, not the logical sense - but those get to be disclaimed.
FWIW, I certainly didn't read his comment that way, and in light of his explicit denial that that's what he intended maybe you should reconsider whether there are alternate interpretations available.
Are you reading some of the other comment threads he's participating in? It seems like he's taking this whole thing very personally, and it's hard to pin down exactly what he's trying to say when he won't calm down.
He wants me to call him, as if escalating this will be worth it...
He didn't even answer your very reasonable question above. Don't you wonder why that is?
> Are you reading some of the other comment threads he's participating in? It seems like he's taking this whole thing very personally, and it's hard to pin down exactly what he's trying to say when he won't calm down.
Feeling misinterpreted can be very personal. That said, in both my initial reading and my re-reading you come off worse than he does.
> He wants me to call him, as if escalating this will be worth it...
Sometimes text-conversation-on-the-internet escalates when neither party intends it, and switching to other modalities can be valuable. That said, it's not at all clear to me that it's a good idea here compared to dropping it.
> He didn't even answer your very reasonable question above. Don't you wonder why that is?
I presumed you'd value a third-party perspective, particularly as you seemed to be appealing to it in the previous comment. I don't think you care much about me in particular beyond that. ¯\_(ツ)_/¯
It's literally not my stance. And I've literally said that it's not my stance—in a comment (that should have never been necessary to begin with) meant to remove all doubt. And you know this.
To continue saying otherwise (explicitly, even) is a case of outright intellectual dishonesty.
