<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 7/6/19 11:22 PM, Sven Panne wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANBN=msGt7=aMD81n8diVXHKy_1JL7T_eDZbQDPxoKM+AsWHyA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">Am Sa., 6. Juli 2019 um 19:06 Uhr schrieb Bryan
          Richter <<a href="mailto:b@chreekat.net"
            moz-do-not-send="true">b@chreekat.net</a>>:<br>
        </div>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">[...] Rather than argue
            against GHC's current practices, however, I would like <br>
            to understand them better. What issues led to a rebase-only
            workflow? <br>
            Which expert opinions were considered? What happy stories
            can people <br>
            relate? We recently switched away from a rebase-only
            workflow at <br>
            $workplace, and it's already made life so much nicer for us
            -- so I'm <br>
            curious what unforeseen pain we might be in for. :)</blockquote>
          <div><br>
          </div>
          <div>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.</div>
        </div>
      </div>
    </blockquote>
    <p>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?<br>
    </p>
    <p>-Bryan<br>
    </p>
    <p>[1]: Stated by Greg Kroah-Hartman in a few of his talks, like
      <a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=L8OOzaqS37s">https://www.youtube.com/watch?v=L8OOzaqS37s</a> or 
      <a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=vyenmLqJQjs">https://www.youtube.com/watch?v=vyenmLqJQjs</a> .</p>
  </body>
</html>