Gitlab workflow

[Bryan Richter]

On 7/7/19 7:53 PM, Sven Panne wrote:> Am So., 7. Juli 2019 um 17:06
Uhr schrieb Bryan Richter <b at chreekat.net >:

 > > 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.