  Research in automatic program repair has shown that real bugs can be
automatically fixed. However, there are several challenges involved in such a
task that are not yet fully addressed. As an example, consider that a
test-suite-based repair tool performs a change in a program to fix a bug
spotted by a failing test case, but then the same or another test case fails.
This could mean that the change is a partial fix for the bug or that another
bug was manifested. However, the repair tool discards the change and possibly
performs other repair attempts. One might wonder if the applied change should
be also applied in other locations in the program so that the bug is fully
fixed. In this paper, we are interested in investigating the extent of bug fix
changes being cloned by developers within patches. Our goal is to investigate
the need of multi-location repair by using identical or similar changes in
identical or similar contexts. To do so, we analyzed 3,049 multi-hunk patches
from the ManySStuBs4J dataset, which is a large dataset of single statement bug
fix changes. We found out that 68% of the multi-hunk patches contain at least
one change clone group. Moreover, most of these patches (70%) are
strictly-cloned ones, which are patches fully composed of changes belonging to
one single change clone group. Finally, most of the strictly-cloned patches
(89%) contain change clones with identical changes, independently of their
contexts. We conclude that automated solutions for creating patches composed of
identical or similar changes can be useful for fixing bugs.
