Gitlab workflow

[Ben Gamari]

Bryan Richter <b at chreekat.net> writes:

> 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.
>
I would reiterate this. In my experience when I'm looking back at GHC's
history I'm probably doing so for one of a few possible reasons:

 * I want to know which patch broke something
 * I want to know which patch made something slower
 * I want to know which patch added something

In all of these cases I (personally) find a linear history makes
reasoning about the progression of changes much easier. Bisection,
blame, and performance analysis tools are all much easier when you have
only one "past" to worry about.

> 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.
>
I strongly disagree here. In my experience, resolving conflicts via
rebase is much easier than doing so via merge (which is one of the
reason why I personally use a rebase workflow even outside of GHC).

The difference is that during a rebase workflow I can reason about the
changes made by each commit individually. I can look at the diff of the
original commit (which is generally small, if history was constructed
well), refer to the relevant subset of changes from the new commits I'm
rebasing on top of, and adapt my changes needing only this "local"
state.

By contrast during a merge I need to keep both the entirety of my branch
as well as every new commit that I'm merging into in my head. Not only
is this often plain infeasible (e.g. I can't imagine trying to do this
with the recent concurrent GC patches), but you end up with a result
that is incoherent since changes that were likely relevant to your
feature branch commits end up recorded in the merge commit.

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

I'm not sure I see the value in this. To me it seems like the merge
resolution is just another step in the *development* of the patch. We
generally don't preserve such steps in history. We only care about the
fully-consistent state of the patch when it is merged.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190711/3b90d8aa/attachment.sig>