[cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

[Jameson Nash via cfe-dev]

> The way it decides that there are "outdated comments" and that those
comments should be hard to does not win it any points in my book (Hubert
Tong)

IIUC, Github has recently changed this, and is now more like Phabricator.
(in that it now seems to add a mark to say the diff is likely outdated, but
has a separate "Resolve Conversation" button). That said, this might bring
up a different incentive for staying with Phabricator, which is that Github
can and does make minor changes to their PR workflow over time, while LLVM
would retain more control over their Phabricator instance.


> Full disclosure: "Revert" commits also wreak havoc on "git bisect" and
"git blame"

As an outsider, I'm not sure I fully understand the comments about `git
bisect` (and blame) not being able to deal with merge and revert commits.
Having worked mostly on the JuliaLang project (which does not discourage
merge commits), we've not typically had much difficulty with either. The
bisect tool is intelligent about being able to isolate which branch of the
graph introduced (or fixed) the behavior of interest, and can isolate
within that branch which commit first show the change. The presence of a
revert commit can be a minor speed-bump (especially if it means the build
previously failed), but "wreak havoc" seems like a bit of hyperbole for
needing to call git blame again—and doesn't seem much different from how
svn would necessarily handle the same situation?

One point that may be worth mentioning though is that merge commits are
also themselves unrestricted changes(*), which can be an interesting gotcha
(it's hard to represent this diff). So if merges are allowed in the
timeline, LLVM may additionally decide whether to permit human-assisted
merges, or to ask that developers rebase the branch first in that case.
(*In git, each commit is a record of the state of all contents of the repo,
plus one or more parent links to the previous state. A merge commit is
distinct only in that it has multiple parents that are indicated as
contributing in some way to the final state, but they aren't otherwise
restricted in what gets changed.)

There is however a philosophic difference of various git coding styles that
LLVM can chose. One school of thought suggests that you should never rebase
code, and instead frequently merge branches in all directions. This gives
the advantage that a `git bisect` attempt will be considering the code as
originally written, and so the result of `git bisect` or `blame` may be
more likely to tell whether a later discovered issue (or other archeology
reason) arose from an issue with the original commit, or arose as a result
of a conflict with a simultaneous change.

A counter school of thought instead argues for preserving a simpler (or in
the limit, a linear) ordering of all commits. I won't say as much about
this, since I think the benefits of this are already obvious to a community
that already requires it.

I also won't say that one school is better or worse than the other (I
happen to use a hybrid in most of my projects). There are also other
approaches to commit management I haven't mentioned, but I wanted to at
least share some thoughts, in the hopes that someone might find the
information useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190204/bfe7814f/attachment.html>