[llvm-dev] [cfe-dev] [lldb-dev] [GitHub] RFC: Enforcing no merge commit policy

[David Greene via llvm-dev]

Artem Dergachev via cfe-dev <cfe-dev at lists.llvm.org> writes:

> If you're doing merge commits, you might lose linear history, but you
> obtain another fancy invariant: every piece of work - i.e., every
> patch, every merge conflict resolution - appears in the repository
> exactly once, under a unique identifier, and the non-linear source
> control history becomes an accurate representation of the real history
> of development.

One consequence of this is that release branches can be more easily
validated.  In a world with merge commits, many projects make fixes on
the release branch *first*, then merge the release branch to master,
ensuring that fixes in the current release make it into the next release
(when that is branched off master in the future).  The history graph
then shows which commits on the release branch made it into master.  If
the final release branch is not reachable from master via the history
graph, you know you missed moving some release fixes into master.  Part
of release validation then simply does "git branch --contains <release>"
and checks that "master" is in the output.

There are various tools to attempt the same vaildation when
cherry-picking commits from master to release, but they rely on metadata
on the cherry-picked commit (like the commit message with cherry-pick
-x) and are thus somewhat fragile.  I don't know of any tools that
verify that fixes made on master make it to the release branch though
I'm sure they exist somewhere.  They would require some kind of list of
commits on master that the release manager wants to see on the release
branch.

So there is a real benefit to merge commits beyond simply recording some
notion of "real history."

I'm not at all suggesting that LLVM adopt this model.  I'm just
describing some of the utility of merge commits for those less familiar
with git.

                          -David