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

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

On Fri, Mar 22, 2019 at 04:39:26PM +0000, David Greene via llvm-dev
wrote:
> 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).
This always felt strongly like a design deficit of git and not a feature
that should be advertised. That is, lack of proper cherry-picking meta
data is the main bug and the back-way model of committing to the oldest
release branch first is the consequence.

Joerg

On Fri, Mar 22, 2019 at 3:40 PM Joerg Sonnenberger via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Fri, Mar 22, 2019 at 04:39:26PM +0000, David Greene via llvm-dev wrote:
> > 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).
>
> This always felt strongly like a design deficit of git and not a feature
> that should be advertised. That is, lack of proper cherry-picking meta
> data is the main bug and the back-way model of committing to the oldest
> release branch first is the consequence.

I'm not sure I understand? In a model where you would commit to trunk and
cherry-pick to a release branch, and never commit directly to the release
branch (which looks like what LLVM is doing), what is the issue with the
lack of cherry-picking metadata?

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190322/06cce3d5/attachment.html>

On Fri, 22 Mar 2019 at 23:41, Joerg Sonnenberger via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
>
> This always felt strongly like a design deficit of git and not a feature
> that should be advertised. That is, lack of proper cherry-picking meta
> data is the main bug and the back-way model of committing to the oldest
> release branch first is the consequence.
>
git cherry-pick -x  will append a line that says "(cherry picked from
commit ...)" to the original commit message in order to indicate which
commit this change was cherry-picked from.

It is not "metadata", but could serve the same purpose.

.Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190323/e6c154dd/attachment.html>