Am Sa., 6. Juli 2019 um 19:06 Uhr schrieb Bryan Richter <b@chreekat.net>:

[...] Rather than argue against GHC's current practices, however, I would like
to understand them better. What issues led to a rebase-only workflow?
Which expert opinions were considered? What happy stories can people
relate? We recently switched away from a rebase-only workflow at
$workplace, and it's already made life so much nicer for us -- so I'm
curious what unforeseen pain we might be in for. :)

I've worked for several companies of several sizes, and from my experience the rule is: The bigger the company, the more there is a tendency to use a rebase-only workflow, with big/huge projects exclusively relying on rebases, explicitly forbidding (non-fast-forward) merges.

How does the scaling argument reconcile with the massive scope of the Linux kernel, the project for which git was created? I can find some middle ground with the more specific points you made in your email, but I have yet to understand how the scaling argument holds water when Linux trucks along with "4000 developers, 450 different companies, and 200 new developers each release"[1]. What makes Linux special in this regard? Is there some second inflection point?

-Bryan

[1]: Stated by Greg Kroah-Hartman in a few of his talks, like https://www.youtube.com/watch?v=L8OOzaqS37s or  https://www.youtube.com/watch?v=vyenmLqJQjs .