<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2019, at 08:28, David Greene <<a href="mailto:greened@obbligato.org" class="">greened@obbligato.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Daniel Sanders via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> writes:<br class=""><br class=""><blockquote type="cite" class="">Personally, I'd like us to drop the linear history requirement but I<br class="">know there's some strong opposition there. The main reason I'd like us<br class="">to accept non-linear history in conjunction with pull requests is that<br class="">it means that the commits that were tested (whether by the author or<br class="">by CI) still exist in the repository after the merge. If we<br class="">rebase+push like we do today or squash+merge as in this proposal, then<br class="">the information that a particular commit passed testing (or failed a<br class="">particular test) gets lost.<br class=""></blockquote><br class="">-1 from me. We have one project where we decided to "keep the original<br class="">commits" as you say above and another where we enforce linear history.<br class="">The linear history project is *much* easier to follow.</div></div></blockquote><div><br class=""></div><div>FWIW, I can't say I've had any real difficulty following non-linear history. I think that's mainly because even non-linear history has a linear history in it (the first-parent one that that article is trying to protect). Then in addition to the linear first-parent history you have more detailed linear histories on the side if you want to see them. It's certainly possible to get into a mess if your pull requests contain merge commits though.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">With merge<br class="">commits you start running into issues like foxtrot commits<br class="">(<a href="https://blog.developer.atlassian.com/stop-foxtrots-now" class="">https://blog.developer.atlassian.com/stop-foxtrots-now</a>) and the whole<br class="">thing easily becomes a mess. There may be various rules/plugins/etc.<br class="">that attempt to enforce "good" behavior but in the long run my<br class="">experience has been that simpler rules make things simpler.<br class=""><br class=""> -David<br class=""></div></div></blockquote><br class=""></div><div>The rule you need to avoid those kinds of mess is essentially the same one as the one we currently have for pushing directly to master: No merge commits in the pull request.</div><div>Or to put it another way that accounts for push to master and pull requests: Humans aren't allowed to make merge commits.</div><div><br class=""></div><div>From that article:</div><div>> You could disable direct pushes to master, and hope that pull-requests never merge with fast-forward. </div><div><br class=""></div><div>That's actually how our downstream repo works except we don't rely on hope. The server is the one merging pull requests and it's doing the merge with --no-ff. It's the equivalent of the 'Create merge commit' option in GitHub.</div><div><br class=""></div><div>Based on reading GitHub's documentation (<a href="https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request#merging-a-pull-request-on-github" class="">https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request#merging-a-pull-request-on-github</a>) all three of the options for merging pull requests will preserve a good first-parent linear history. GitHub doesn't ban pushing to master of course and we shouldn't do that as it will make pull-requests mandatory.</div></body></html>