[llvm-dev] Flang landing in the monorepo

[Brooks Davis via llvm-dev]

On Wed, Dec 18, 2019 at 10:19:20PM +0100, Alexander Richardson via llvm-dev wrote:
> On Wed, 18 Dec 2019 at 17:44, Alex L via llvm-dev <llvm-dev at lists.llvm.org>
> wrote:
> 
> > I think that it would be beneficial for the maintainers of the downstream
> > llvm-project repositories if there was a single merge commit instead of
> > 2700. In my organization, the auto merging infrastructure tests and merges
> > upstream changes one commit at a time, without exceptions, unless there's a
> > span of commits with a broken build. It's not cut out to handle 2700
> > incoming commits, but it can handle a merge commit that merges in 2700
> > commits just fine, as it's only merging in the "first-parent" commits from
> > the upstream branch. If the community were to decide to commit 2700 commits
> > directly, we would need to shut down our infrastructure for several hours,
> > and merge things through manually. Additionally, I'm not sure if our CI (
> > http://lab.llvm.org:8080/green/) will be able to handle 2700 commits
> > coming in at the same time, so we'd need to possibly manually hand hold it
> > through as the commits are coming in.
> >
> > Thanks,
> > Alex
> >
> 
> 
> In order to allow bisecting, we also merge one commit at a time in the
> CHERI fork of LLVM.
> However, we don't (yet) have the infrastructure to test each individual
> commit. Therefore, in our case this would just increase the time it takes
> us to perform the merge (~0-3 seconds per commit, so about 1 hour of CPU
> time since there shouldn't be any conflicts) and will generate 2700
> additional merge commits in our history.
> I would prefer a single merge commit since that is easier for us but I
> don't have a strong preference.

So long as all the commits where in a single batch, we could also work around
this in CHERI-LLVM by merging up to the commit before the batch and then
merging the whole lot as a single merge commit.  We'd lose the ability
to bisect within the block, but that would be same as if it landed as a
single commit.

-- Brooks

> > On Wed, 18 Dec 2019 at 08:04, James Y Knight via llvm-dev <
> > llvm-dev at lists.llvm.org> wrote:
> >
> >> On Wed, Dec 18, 2019 at 4:56 AM Peter Waller <Peter.Waller at arm.com>
> >> wrote:
> >>
> >>> On 17/12/2019 22:25, James Y Knight wrote:
> >>> > I think it would probably make the most sense to land this as a single
> >>> > merge-commit (from the 2700-commit rewritten history you've created)
> >>> > onto llvm-project master, rather than as 2700 individual toplevel
> >>> > commits to master. (Which means: disable the merge-commit prohibition
> >>> > in the github configuration, temporarily, push this commit, and then
> >>> > enable it again).
> >>>
> >>> I understood that the LLVM project did not accept any merge commit so
> >>> far. It seems a shame to make an exception if we don't have to
> >>
> >>
> >>>
> >> Can you elaborate on the perceived benefits of having it as a merge?
> >>>
> >>
> >> The rule against merge commits is primarily because we want to encourage
> >> people to make reasonable separate commits to master which are sensible
> >> (reviewable, buildable, etc) in isolation. And, to make it so the history
> >> is more easily understandable to humans. It's not only that we don't want
> >> merge commits -- we actually don't really want people doing merges, in
> >> general.
> >>
> >> But, here we actually *do* have a merge, because flang was developed
> >> externally. This is an exceptional circumstance (and I'm sure we'll have a
> >> few more). Using a merge commit in this circumstance makes it easier for
> >> humans looking at history to understand what's going on here, rather than
> >> harder -- because it actually marks the merge as being a merge. That's the
> >> main reason why I think we ought to use a merge commit here.
> >>
> >> Additionally (and less importantly), I'm going to presume that many/most
> >> of the 2700 commits cannot actually be built. So, having a single merge
> >> commit within which the unbuildable sub-commits are contained will also
> >> make things better for autobuilders.
> >>
> >>
> >>>  It's of course technically straightforward to push either "follow-on
> >>> commits" or a merge commit.
> >>>
> >>> I think there could be a benefit to having it as a "follow-on commits",
> >>> in that checking out an old flang commit won't have the effect of
> >>> deleting the rest of the llvm monorepo. Granted, this may be a slim
> >>> benefit since it will be a fairly arbitrary revision of the llvm
> >>> monorepo, taken at the point of the initial push.
> >>>
> >>
> >> I'm suggesting to build the history the exact same way you are currently,
> >> and then simply merging it onto master with a single merge commit ("git
> >> merge --no-ff"), rather than "fast-forwarding" the entire set of commits.
> >> So this is not a benefit, it'd be the same either way.
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev