<div dir="ltr"><div dir="ltr">Am So., 7. Juli 2019 um 17:06 Uhr schrieb Bryan Richter <<a href="mailto:b@chreekat.net">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">
  
    
  
  <div bgcolor="#FFFFFF">
    <div class="gmail-m_-1886502185527181341moz-cite-prefix">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?</div></div></blockquote><div><br></div><div>Well, somehow I saw that example coming... :-D I think the main reason why things work for Linux is IMHO the amount of highly specialized high-quality maintainers, i.e. the people who pick the patches into the (parts of) the releases they maintain, and who do it as their main (sole?) job. In addition they have a brutal review system plus an army of people continuously testing *and* they have Linus.</div><div><br></div><div>Now look at your usual company: You have average people there (at best), silly deadlines for silly features, no real maintainers with the power to reject/revert stuff (regardless of any deadline), your testing is far from where it should be etc. etc. Then you do everything to keep things as simple as possible, and having a repository with no merge commits *is* much easier to handle than one with merges. If you are happy with merge commits, by all means continue to use them. The "right" way of doing things depends on so many factors (project size/complexity, number/qualification of people/maintainers, release strategy/frequency, ...) that there is probably no silver bullet. The good thing is: Git doesn't prescribe you a special kind of workflow, it is more of a toolbox to build your own.</div><div><br></div><div>I would very much like to turn the question around: I never fully understood why some people like merge-based workflows so much. OK, you can see that e.g. commits A, B, and C together implement feature X, but to be honest: After the feature X landed, probably nobody really cares about the feature's history anymore, you normally care much more about: Which commit broke feature Y? Which commit slowed down things? Which commit introduced a space leak/race condition?</div></div></div>