On 7/7/19 7:53 PM, Sven Panne wrote:> Am So., 7. Juli 2019 um 17:06
Uhr schrieb Bryan Richter
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?
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.
:D I would add to your argument that they appear to use git primarily to *keep a record of merges*. Incoming patches have no history whatsoever; they're just individual patches. I guess that could be considered a simpler-to-use version of the fast-forward-only strategy! Perhaps Linux isn't such a great counterexample after all.... Once they have committed patches to some particular history, though, they don't rebase, since that would rewrite important audit history.
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?
What I *don't* like is rewriting history, for all the reasons I don't like mutable state. As you say, what you're generally interested in is commits. When references to commits (in emails etc.) get invalidated, it adds confusion and extra work. Seeing this happen is what led me to wonder why people even prefer this strategy. On top of that, many of the problems people have with merges actually seem to be problems with bad commits, as you yourself hinted. Other concerns seem to be based in unfamiliarity with git's features, or an irrational desire for "pure history". (Merges *are* history!) One final thing I like about merges is conflict resolution. Resolving conflicts via rebase is something I get wrong 40% of the time. It's hard. Even resolving a conflict during a merge is hard, but it's easier. Plus, the eventual merge commit keeps a record of the resolution! (I only learned this recently, since `git log` doesn't show it by default.) Keeping a public record of how a conflict was resolved seems like a huge benefit. In the end, my main takeaway is that good commits are just as important as good code, regardless of strategy.