<div dir="ltr"><div dir="ltr">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 (<a href="http://lab.llvm.org:8080/green/">http://lab.llvm.org:8080/green/</a>) 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.<div><br></div><div>Thanks,</div><div>Alex</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 18 Dec 2019 at 08:04, James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Dec 18, 2019 at 4:56 AM Peter Waller <<a href="mailto:Peter.Waller@arm.com" target="_blank">Peter.Waller@arm.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 17/12/2019 22:25, James Y Knight wrote:<br>
> I think it would probably make the most sense to land this as a single <br>
> merge-commit (from the 2700-commit rewritten history you've created) <br>
> onto llvm-project master, rather than as 2700 individual toplevel <br>
> commits to master. (Which means: disable the merge-commit prohibition <br>
> in the github configuration, temporarily, push this commit, and then <br>
> enable it again).<br>
<br>
I understood that the LLVM project did not accept any merge commit so <br>
far. It seems a shame to make an exception if we don't have to </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Can you elaborate on the perceived benefits of having it as a merge?<br></blockquote><div> </div><div>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.</div><div><br></div><div>But, here we actually <i>do</i> 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.</div><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> It's of course technically straightforward to push either "follow-on <br>
commits" or a merge commit.<br>
<br>
I think there could be a benefit to having it as a "follow-on commits", <br>
in that checking out an old flang commit won't have the effect of <br>
deleting the rest of the llvm monorepo. Granted, this may be a slim <br>
benefit since it will be a fairly arbitrary revision of the llvm <br>
monorepo, taken at the point of the initial push.<br></blockquote><div><br></div><div>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.</div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>