[swift-dev] Merge-commit noise?
jordan_rose at apple.com
Sat Dec 5 12:46:28 CST 2015
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.
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 "Incremental Development <https://swift.org/contributing/#incremental-development>" policy on the website.)
The history may be overly colorful, but it's also a more accurate representation.
> On Dec 5, 2015, at 10:33 , David Zarzycki <zarzycki at icloud.com> wrote:
> If one uses the command-line to merge branches, rather than GitHub, you can avoid many of these “noisy” merge commits. For background, see: http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html
>> On Dec 5, 2015, at 02:15, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
>> Now that contributions are being made on GitHub, it seems there is a lot of noise in the repo's history from merge commits.
>> Would it make sense to instate a policy where commits must be rebased on top of master before merging/pushing?
>> (The rebase would have to be done by folks with commit access—namely Apple employees, for now.)
>> Just a thought,
>> Jacob Bandes-Storch
>> swift-dev mailing list
>> swift-dev at swift.org
> swift-dev mailing list
> swift-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev