<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">In this case having merge commits is a feature: it records both the original contributor and the Swift team member who accepted it. I know Git allows us to record such information in a single commit, but this doesn't require any extra work.</div><div class=""><br class=""></div><div class="">Another point is that we strive to have every commit on the master branch build and pass all the tests. That doesn't always happen, of course, but the closer we get to that, the better we can do when bisecting the commit history to find when an issue was introduced. Because not everyone submitting a patch has necessarily maintained that rigor (particularly not after rebasing), we use the merge commit to make multiple out-of-tree commits atomic. (But we will send back large pull requests in favor of several smaller ones, per the "<a href="https://swift.org/contributing/#incremental-development" class="">Incremental Development</a>" policy on the website.)</div><div class=""><br class=""></div><div class="">The history may be overly colorful, but it's also a more accurate representation.</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 5, 2015, at 10:33 , David Zarzycki <<a href="mailto:zarzycki@icloud.com" class="">zarzycki@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">If one uses the command-line to merge branches, rather than GitHub, you can avoid many of these “noisy” merge commits. For background, see: <a href="http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html" class="">http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html</a><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Dec 5, 2015, at 02:15, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>> wrote:<br class=""><br class="">Now that contributions are being made on GitHub, it seems there is a lot of noise in the repo's history from merge commits.<br class=""><br class=""><image.png><br class=""><br class="">Would it make sense to instate a policy where commits must be rebased on top of master before merging/pushing?<br class=""><br class="">(The rebase would have to be done by folks with commit access—namely Apple employees, for now.)<br class=""><br class="">Just a thought,<br class="">Jacob Bandes-Storch<br class=""> _______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></div></blockquote></div><br class=""></body></html>