Automatic clustering of code changes

Abstract

Several research tools and projects require groups of similar code changes as input. Examples are recommendation and bug finding tools that can provide valuable information to developers based on such data. With the help of similar code changes they can simplify the application of bug fixes and code changes to multiple locations in a project. But despite their benefit, the practical value of existing tools is limited, as users need to manually specify the input data, i.e., the groups of similar code changes.To overcome this drawback, this paper presents and evaluates two syntactical similarity metrics, one of them is specifically designed to run fast, in combination with two carefully selected and self-tuning clustering algorithms to automatically detect groups of similar code changes.We evaluate the combinations of metrics and clustering algorithms by applying them to several open source projects and also publish the detected groups of similar code changes online as a reference dataset. The automatically detected groups of similar code changes work well when used as input for LASE, a recommendation system for code changes.

SPIDER: Enabling Fast Patch Propagation In Related Software Repositories

“…Long et al [51], in contrast with the previously mentioned studies, use machine learning to model correct code and generate generic defects fixes, but do not focus on propagating existing patches as we do in this study. Similar to what we do in this work, Kreutzer et al [43] use AST differencing on changes to extract metrics to help cluster the changes by similarity.…”

Mining Change Histories for Unknown Systematic Edits

“…The most closely related work, where change data is mined, is that of Negera et. al [21] and [22] Kreutzer et. al.…”

Almost Rerere: An Approach for Automating Conflict Resolution from Similar Resolved Conflicts

“…To evaluate the quality of the automatic resolution provided by Almost Rerere, it was necessary to know the actual resolutions committed by developers and use them as ground-truth. In [16], nine data sets based on Git repositories from active Java open-source projects were created by extracting all the differences between the sequential commits to the master branch. From six such repositories, we extracted all the single-line changes and used them as conflicts resolved by developers.…”