[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits (original) (raw)

Jameson Nash via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 4 11🔞02 PST 2019

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/llvm-dev/attachments/20190204/bfe7814f/attachment.html>

More information about the llvm-dev mailing list