You should be pushing for GitHub to improve their commit display instead of celebrating them adding something that lets you contort your history to work around it.
Right, because GitHub is obviously the only tool I, or any of my contributors, use that has a git history. (Yes, I know about whatever command line flags you're suddenly feeling the urge to tell me about)
Edit: And for fucks sake can't I be happy GitHub implemented an outstanding feature request I've personally been asking for years? The cynicism from some of the people on this site really gets to me sometimes. Stop.
It seems you don't actually understand the complaint, and are resorting to a schoolyard "no you" tactic to try and deflect.
The problem is that this merge option is considered by many to be actively harmful, and GitHub adding support for this is basically them tacitly saying that this is a perfectly fine merge method to use. This will almost certainly cause an increase in the number of people using this merge method, which is a shame as it really should be discouraged instead of encouraged.
The other problem is the main argument in favor of this merge method is the fact that GitHub displays non-linear commit histories terribly. That should not be an argument in favor of having a poor merging strategy, that should be an argument in favor of GitHub revamping their commit history display to actually be useful.
I fully understand the complaint. I also understand that this is not up to you to decide.
It is not up to you to decide other people's and teams' workflows. It is not up to you to decide what is or isn't harmful in the context of another team. And it is certainly not up to you to decide that GitHub shouldn't provide features their paying customers are asking for, because of concerns of a completely different context and workflow.
I appreciate that you are more than familiar with git, but that doesn't give you free reign to decide what is and isn't an antipattern for other people. In fact, you should understand far better than the average HN user just how absurd your reasoning is if you'd step back from it a little.
What you call antipattern, a lot of people call feature. If GitHub now clashes with you on a philosophical level, consider moving to GitLab (oh, wait, GL has supported this and far worse for a far longer time).
The developers using rebase flows do not affect your life. They do not affect your work. They, and their "antipatterns", are as harmful to you as an iOS user is to an Android one. And your merge flow does not affect me. What does affect me is reading constant unwarranted negativity on Hacker News, a community where my expectations have so far been above those of reddit's unending stream of cynicism. And it bugs me far, far more that this has been your reaction to a company listening to its customer base, than you or I could ever care about deciding what flow is or isn't an antipattern.
It sounds to me like you're saying that nobody can criticize anything, which is complete bullshit. Yes I absolutely can declare that something is an antipattern. You're free to disagree with me, but that doesn't mean I can't express my opinion, or that I can't be disappointed when a company like GitHub tacitly endorses the antipattern instead of improving their tooling to eliminate the main reason why people reach for that antipattern.
> The developers using rebase flows do not affect your life.
Yes they do. If they didn't affect my life, I wouldn't care. But every time I have to deal with an open-source project that adopts this workflow, it affects me. Every time I end up working on a project that's adopted this workflow, it affects me. And it affects me in more subtle ways too, such as tooling being geared around a largely-linear history instead of a history with lots of merges (e.g. GitHub's commit history display).
> And it bugs me far, far more that this has been your reaction to a company listening to its customer base
They're barely listening. There's a long list of far more valuable changes they could make, that they're not doing, because they seem to not really care. It took an extremely long time, a very high-profile blog post calling them out, and competition from GitLab for them to finally start improving the core of their product (pull requests), and they're still missing a lot of useful functionality (e.g. rebase tracking). And of course they haven't even touched the commit history display, even though, as has been mentioned multiple times, it really sucks for a non-linear history. In fact, most of their product hasn't improved in a long time.
