Investigation and Detection of Split Commit
Ryo Arima, Yoshiki Higo, and Shinji Kusumoto
Graduate School of Information Science and Technology, Osaka University, Japan{r-arima, higo, kusumoto}@ist.osaka-u.ac.jp

Abstract—Each commit in repositories of version control systems should include code changes for only a single task. However,in real repositories, there are many commits for multiple tasks
and tasks split into multiple commits. We call the latter splitcommits. In this research, we firstly investigate how many andwhat kinds of split commits are included in repositories. Then,we classify the found split commits into three categories. Basedon the classification, we propose a new technique to detect split
commits automatically. This is the first research that proposesa technique to detect split commits. To evaluate the proposedtechnique, we apply it to repositories of two open source software.
The results show that the proposed technique detects split
commits with high accuracy (precision is 0.8 and F-measure is0.7).
Index Terms—Version control system, Split commit.

I. I NTRODUCTION
When we use version control systems for software development, a meaningful set of code changes such as a bugfix or a functional addition should be a single commit. In
this research, we call such a meaningful set of code changes
task. Previous research studies revealed that commits including
multiple tasks, which they call tangled commits, have negative
impacts on performance of repository analyses [1]. There arealso several research studies proposing techniques to split
tangled commits into different appropriate commits [1] [2].
However, there is no research on merging commits into which
a task is split as a single appropriate commit. In this research,
we call such a pair of commits containing a split task splitcommit. The followings are main issues caused by the presenceof split commits.
Performance decrement of repository analyses such as anevolutional coupling [3][4][5].
• Understandability decrement of past commits.
•

The contributions of this research are as follows:investigating how many and what kinds of split commits
are included in repositories, and• proposing a new technique to find split commits automatically.
•A. Investigation approach
The targets of this investigation are 100 commits in tworepositories, Apache Commons Collection1 and Retrofit2 . We
manually checked whether every pair in these commits was a
split commit or not.
B. Results
We found that 81 split commits were included in both
repositories by checking 1,714 commit pairs. By investigating
characteristics of the 81 split commits in more detail, wecategorized them with the following three-level classification.
1) Level-1 (snippet level changes): In Level-1, c2 need not
be a single independent commit at all. For example, adding
some changes for overlooked code fragments or reverting
previous changes are Level-1. In Level-1, c1 and c2 change
the same or very closely located code.
2) Level-2 (method level changes): In Level-2, the changes
in c2 depend on the changes in c1 . In most cases of Level-2,
two methods having a calling or an inheritance relationship arechanged in c1 and c2 . For example, a commit adding a new
method and a commit adding calling the method to anothermethod are Level-2 split commit.
3) Level-3 (function level changes): In Level-3, changes inc1 and c2 are adding, deleting or modifying functions of thesame class or module. For example, a commit adding a gettermethod for a member of a class and a commit adding a settermethod for the same member form a Level-3 split commit.
Table I shows the number of the detected split commits
from the viewpoint of this classification. Based on the above
features of each level split commit, we propose an automatic
detection technique of split commits in the next section.
III. O UR TECHNIQUE FOR S PLIT COMMIT DETECTION
Our technique takes a pair of commits as input, and it
outputs whether the pair is a split commit or not.
First, our technique constructs a graph from source code ateach commit of the input automatically. Each vertex in thegraph represents a method in the source code. Method m in

II. I NVESTIGATION OF S PLIT COMMIT
As the first step of this research, we investigated how
many and what kinds of split commits existed in development
histories. In this research, we defined that a pair of commits
c1 and c2 is a split commit if both the commits contain thesame task. If there are more then two commits containing thesame task, every pair in the commits is a split commit.

TABLE ID ETECTED SPLIT COMMITSApacheRetrofit

134

Level-1(0.9%)(1.7%)

219

Level-2(1.4%)(3.9%)

1 https://github.com/apache/commons-collections
2 https://github.com/square/retrofit

49
32

Level-3(3.3%)(14.0%)

class X{
void a(){}}

class X{
void a(){}}

class Y{
void b(){a();}}

class Y{
void b(){a();}void c(){}}(a)commit c1

IV. EXPERIMENTATION
To evaluate our proposed technique, we conducted experiments on repositories of open source software.

a2a1c2b2b11)

2)

3)4)

(c)constructed graph(b)commit c2Fig. 1. The graph constructed from source code.

a2

a1

a2

a1

A. Targets
We applied our proposed technique to two targets. Target 1
is 1,714 pairs of commits obtained by the investigation of thetwo repositories in Section II. As evaluation measures of thisexperiment, precision, recall and F-measure were calculated
by comparing the output of the proposed technique with theresults of the investigation.
Target 2 is 18,619 pairs of commits in the same repository as
the investigation described in Section II. By checking manuallywhether each pair regarded as a split commit by the technique
was correct or not, precision was calculated.
B. Resultsb1b2c2(a)split commit

b1c2b2(b)not split commt

Fig. 2. Distinguish split commits.

commit cn is represented as mn in this paper. Each edge in thegraph means that their methods have either of the following
relationships.
1) The two methods in the two commits are the same.
2) The method calls the other method.
3) The method is called by the other method.
4) The methods are defined in the same class.
The proposed technique constructs a graph shown in Figure1(c) from two commits shown in Figures 1(a) and 1(b).
Then, the proposed technique determines whether the given
two commits are a split commit or not based on the distance
between vertices representing modified methods. If the distance between modified methods is shorter than the threshold,the technique regards the input as a split commit. In Figure
2, highlighted vertices represent modified methods, and thickarrows represent the shortest paths from a modified method
to another nearest modified method. A graph shown in Figure2(a) is a split commit because the distance between modified
methods is short, whereas a graph shown in Figure 2(b) is nota split commit because the distance between modified methods
is long.

TABLE IIR ESULTS OF THE EXPERIMENT.

Collections
Retrofit

precision
0.714
1.000

Target 1
recallF-measure
0.714
0.714
0.594
0.745

Target 2
precision
0.822
0.884

Table II shows the results. F-measure of target 1 was 0.7,
and precision of target 2 was 0.7. Our proposed technique is
useful for split commits detection.
In cases where the technique detected split commits by
mistake, there were pairs of commits that methods modified atmany commits were modified at both commits. For example,
entry points of software such as main methods are modified
at many commits.
V. C ONCLUSION
In this research, we manually checked two repositoriesof open source software and found 81 split commits. We
also classified them into three categories. Then, we proposed
an automatic detection technique of split commits with theheuristics that we had derived from the manual checking.
In our evaluation, F-measure and precision of the proposed
technique are 0.7 and 0.8, respectively.
In the future, we are going to investigate the effect of split
commits on performance of repository analyses.
ACKNOWLEDGEMNTThis work was supported by JSPS KAKENHI Grant Number JP25220003.
R EFERENCES[1] K. Herzig and A. Zeller, “The Impact of Tangled Code Changes,” in Proc.
of the 10th International Workshop on Mining Software Repositories,
2013, pp. 121–130.
[2] H. Kirinuki, Y. Higo, K. Hotta, and S. Kusumoto, “Hey! are you committing tangled changes?” in Proc. of the 22nd International Conference
on Program Comprehension, 2014, pp. 262–265.
[3] J. M. Bieman, A. A. Andrews, and H. J. Yang, “Understanding changeproneness in OO software through visualization,” in Proc. of the 11th
International Workshop on Program Comprehension, 2003, pp. 44–53.
[4] H. Gall, K. Hajek, and M. Jazayeri, “Detection of logical coupling basedon product release history,” in Proc. of the 1998 International Conference
on Software Maintenance, 1998, pp. 190–198.
[5] T. Zimmermann, P. Weißgerber, S. Diehl, and A. Zeller, “Mining version
histories to guide software changes,” IEEE Trans. Softw. Eng., vol. 31(6),pp. 429–445, 2005.