I. INTRODUCTION
A code clone (in short, clone) is a code fragment that is identical or similar to other code fragments in source code. Code cloning has been pointed out as one of the major prob- lems in the maintenance process of software development [1]. Thus, there are many studies on simultaneous modification and refactoring support for clones [2], [3]. An existing study proposed a clone change notification tool, Clone Notifier, to improve the efficiency of these tasks [4]. Clone Notifier takes two revisions of a target project as inputs and notifies developers of information about clone changes. Clone Notifier is designed for industry use [5] and is premised on one execution a day. On the other hand, Clone Notifier is difficult to be executed triggered by development workflow, such as modifying source code or merging branches because it is not designed to be triggered by external factors except for time. For this reason, we think there are the following issues when considering the use of Clone Notifier in development, such as OSS development, in which modifying source code or merging branches are frequently conducted [6]. ● The first issue is that even if code fragments need modifications as a result of clone changes, the code fragments will not be notified promptly. Because Clone Notifier is executed once a day, once Clone Notifier has been executed, there is a day interval until the next execution. On the other hand, if Clone Notifier users set its execution interval shorter (e.g., five minutes) to solve this issue, information of clone changes is notified to the users frequently even if the source code is not modified. Hence, the notification probably annoys the users. If clone change notification is triggered by development workflow, code fragments to be modified will be notified in line with the development workflow, and the developers will be able to respond to the code fragments promptly. ● The second issue is that if a large amount of source code modifications are conducted, and as a result, many clones may be changed improperly (i.e., many code fragments need modifications), the information is notified all at once. In this case, the users will be forced to check a large amount of clone change information, and they may overlook serious clone changes. If clone change notification is triggered by development workflow, code fragments to be modified are notified in line with each source code modification, and the developers will be able to avoid overlooking serious clone changes. ● The third issue is that code fragments to be modified are probably merged into the main branch when developing with version control systems (in short, VCS). In such development, the main branch should be bug-free and always ready for release. Therefore, code fragments to be modified that may contain bugs should be checked before the topic branch is merged. However, Clone Notifier, which is premised on regular execution, is difficult to de- tect such code fragments before merging topic branches. If clone change notification is triggered by development workflow, the possibility of bugs merged into the main branch can be reduced because such code fragments are detected before merging topic branches. Consequently, in this study, we propose a new clone modi- fication support technique aimed to integrate into pull request based development for solving these issues. The proposed technique detects code fragments that need modifications by tracking clone changes at the time of creating pull requests (in short, PR). Moreover, we made three improvements for more accurate clone change tracking than Clone Notifier. Additionally, we implemented the proposed technique as a software tool, CLIONE¹. To evaluate CLIONE, we conducted two experiments, an investigation of the proportion of PRs in which clones have been modified non-simultaneously (i.e., some of clones were modified but the others were not modified) and a comparison of the results of CLIONE's clone change tracking with the Clone Notifier's one. As a result, 11.9%~30.4% of PRs are in which clones were modified non-simultaneously, and we confirmed that CLIONE was able to track clone changes more accurately than Clone Notifier.
II.  RESEARCH MOTIVATION
Figure 1 shows two methods in JRuby. In PR#5096 2 , while any_pBlockless method was modified, all_pBlockless method was not modified. This non-simultaneous modification introduced a bug that caused an error when calling a Ruby API, which internally calls all_pBlockless method in JRuby into the main branch. As a result, JRuby, which included this bug, was released at version 9.2.0.0. This bug was fixed in PR#5298 3 . If the developers used CLIONE, they could avoid introducing the bug into the main branch. Besides, Clone Notifier cannot find this non-simultaneous modification because any_pBlockless method was entirely changed, and the clone detectors used in Clone Notifier cannot detect the modified method as a clone of all_pBlockless method (detail is explained in Section IV-B). ¹ available at https://github.com/T45K/CLIONE ²https://github.com/jruby/jruby/pull/5096 ³https://github.com/jruby/jruby/pull/5298
III. PRELIMINARIES
A. Code clone
A clone is a code fragment that is identical or similar to another code fragment. A set of code fragments in which any pair is a pair of clones is called clone set. Clones are classified as follows based on the degree of similarity to their correspondences [7]. • Type-1 is an exact copy without modifications (except for white spaces and comments). • Type-2 is a syntactically identical copy; only variables, types, or function identifiers were changed. Type-3 is a copy with further modifications; statements were changed, added, or removed. So far, many clone detection techniques and tools have been proposed and developed [8]. In this paper, we introduce a couple of popular detection techniques that are especially related to this research.
Text-based clone detection
This technique firstly normalizes the target source code and detects clones by comparing code fragments, such as methods or code blocks in the normalized source code. NiCad [9], which detects Type-3 clones from normalized source code by Longest Common Subsequence algorithm, is a well-known text-based clone detection tool.
Token-based clone detection
This technique firstly tokenizes the target source code and detects clones by using the token information. CCFinder [10] and SourcererCC [11] are well-known token-based clone detection tools. CCFinder detects Type-2 clones by comparing token sequences. SourcererCC detects Type-3 clones by using token types and their appearance frequencies.
B.  Clone  Notifier
Tokui et al. developed a tool, Clone Notifier, which sup- ports developers to modify clones [4]. Clone Notifier takes two revisions of a project as inputs, and based on the changes of the source code between the two revisions, it classifies clone sets under four categories: Stable , New , Deleted , and Changed. First, Clone Notifier detects clones from each revision by using existing clone detectors [11]–[13]. Next, it tracks changes of the detected clones. Finally, it classifies clone sets from the results of clone change tracking. Clone Notifier is designed to be premised on regular execution (e.g., once a day).
C. Pull request based development
PR-based development is a development process using PR, which is one of the features of GitHub. PR is a feature that notifies developers of development information, such as source code changes before a branch is merged into another one. In PR-based development, the developers work on not the main branch but topic branches. Once the assigned work is done, the developer creates a PR and notify other developers of the change information, and if the changes have no problems, the topic branch is merged to the main branch. PR-based development is widely adopted by OSS develop- ment [14]. Moreover, some studies have proposed techniques that integrate existing source code analysis techniques into PR based development for more efficient software develop- ment [15], [16].
IV.  Proposed Tool: CLIONE
In this study, we propose a new clone modification support technique aimed to integrate into development workflow. The proposed technique detects code fragments that need modi- fications by tracking clone changes at the time of creating PRs. We implemented the proposed technique as a tool, CLIONE. CLIONE is a server-side application and receives HTTP requests which GitHub sends when developers create PRs. Additionally, CLIONE is implemented based on GitHub Apps 4 , so that it is easy to install CLIONE on GitHub projects.
A. Overview
Figure 2 shows an overview of CLIONE. First, developers who want to use CLIONE register their GitHub accounts and their repositories with CLIONE. After this registration, the developers can use CLIONE by creating PRs. CLIONE tracks clone changes between the head commit of the PR and the commit at the point where the PR branch was created (in short, base commit). When the developer creates a PR, CLIONE downloads (git- clone) the project onto its local environment. Next, CLIONE detects clones from the head and the base commits of the PR, respectively, by using NiCad [9] or SourcererCC [11]. Why we select these clone detectors is each of them can detect Type-3 clones precisely. Next, CLIONE tracks clones to detect clone changes be- tween the two commits. As well as Clone Notifier, to track clones between the two commits, CLIONE calculates the over- lapping location of clones, based on the location overlapping function of Kim et al. [17]. Location overlapping measures how much two code fragments cf1 and cf2 overlap each other (0 ≤ LO(cf1,cf2) ≤ 1). CLIONE uses the difference between the same file in each commit, without the added and deleted lines. It computes the relative proportion of an overlapped region between cf 1 and the calibrated cf 2.
where cf 1 in the base commit spans from the line os to the line o c , and the calibrated location of c f 2 in the head commit spans from the line n s to the line n c . If the location overlapping between the two clones is 30% or more, CLIONE tracks from the clone at the base commit to the clone at the head commit. After clone tracking, based on changes of clones, CLIONE detects non-simultaneously modified clone sets and clone sets to be refactored as code fragments that need modifications. Specifically, CLIONE treats clone sets where some clones were modified but the others were not modified as non- simultaneously modified and clone sets where some or all of clones were newly added as targets of refactoring. Moreover, in CLIONE, we made three improvements for more accurate clone change tracking. We explain the improvements in Sec- tion IV-B. Finally, CLIONE makes a PR comment for each the code fragments to be modified to notify the results to the developer. In this comment, the code fragments are shown. In the case of non-simultaneously modified clones, changed code fragments and non-changed code fragments are shown. In the case of clones to be refactored, all of the target code fragments are shown. Figure 3 shows an example of PR comment about a non-simultaneously modified clone set. In the top of the figure, the changed piece of the changed code fragment is shown in the diff format, the whole of changed code fragment is shown in the middle, and the non-changed code fragment is shown in the bottom. By getting notifications of the results as PR comments, developers can receive feedback promptly. B. Improvements of clone change tracking In CLIONE, we made three improvements to the clone change tracking technique used in Clone Notifier, 1) code fragment tracking, 2) file rename detection, and 3) clone change judgment by comparing token sequences. In this paper, we explain only 1) code fragment tracking because of space limitations. Clone Notifier treats only clone instances (code fragments that are detected as clones) as targets of tracking. Thus, if code fragments that are detected as clones in one of the commits are not detected in the other commit, the code fragments are classified added or deleted clone instances by Clone Notifier. On the other hand, in some cases, a code fragment is not detected as a clone because it has been modified. For example, figure 4(a) shows two methods that are detected as clones in the base commit, but not detected as clones in the head commit because one of them has been modified. In this case, Clone Notifier classifies the clone set (the two methods) as Deleted because the methods are not detected as clones in the head commit. However, this clone set should be classified as non- simultaneous modification because only main1 method was modified. On the other hand, CLIONE tracks not only clone in- stances but also code fragments, such as methods or code blocks. Even if clones are not detected in one of the com- mits, clone changes are trackable by tracking code fragments themselves. In this example, CLIONE tracks the methods themselves (figure 4(b)). As a result, CLIONE can detect a non-simultaneously modified clone set (figure 4(c)) and classify it appropriately. Fig. 4: Improvement of clone tracking
V. EVALUATION
To evaluate CLIONE, we conducted two experiments shown below.
Experiment  1
Experiment 1 is an investigation of the proportion of PRs in which clones have been modified non-simultaneously. In this experiment, we manually executed CLIONE on PRs of target projects and investigated whether clones had been modified simultaneously or not for each of the PRs.
Experiment 2
Experiment 2 is a comparison of the results of CLIONE's clone change tracking with Clone Notifier's one. In this experiment, we executed CLIONE and Clone Notifier on PRs of target projects and manually counted the number of PRs in which the results of clone change tracking of CLIONE and Clone Notifier are different due to code fragment tracking (explained in Section IV-B).
A. Experimental Targets
We selected three OSS as our experimental targets. Table I shows the names of the projects, the number of PRs merged by 20/7/2020, and the number of PRs in which at least a Java file was changed (in short, target PRs). The reason why we selected those OSS is that they are often targeted in clone research [18]–[20] and developed in PR-based development on  GitHub.
B. Results
Results of experiment 1: Table II shows the results of ex- periment 1. In this table, "improper PRs" means PRs in which clones were modified non-simultaneously. All the projects have PRs in which clones were modified non-simultaneously, and their proportions are the range from 11.9% to 30.4%. We consider that if the developers of the projects had used CLIONE, they could have responded to non-simultaneously modified clones in PRs because the clones were notified at the time of creating PRs. Results of experiment 2: As a result of Experiment 2, we confirmed that in total, there were 35 PRs (27.5% of improper PRs) in which CLIONE tracked clone changes more accurately than Clone Notifier. On the other hand, there was no clone change where Clone Notifier succeeded in tracking but CLIONE failed. Therefore, CLIONE is better at clone change tracking than Clone Notifier.
VI.  CONCLUSION
In this study, we proposed a new clone modification sup- port technique aimed to integrate into PR-based develop- ment. The proposed technique detects code fragments that need modifications at the time of creating PRs. Moreover, we implemented the proposed technique as a software tool, CLIONE. As evaluation, we investigated the proportion of PRs in which clones have been modified non-simultaneously, and also we compared the results of clone change tracking with the Clone Notifier. As a result, 11.9%~30.4% of PRs included non-simultaneously modified clones, and we confirmed that CLIONE was able to track clone changes more accurately than Clone Notifier. Currently, CLIONE is available at https: //github.com/T45K/CLIONE. As future works, we consider evaluating usefulness of CLIONE for developers and measuring the response time of CLIONE's notification after a PR was created.

A CKNOWLEDGMENT
This work was supported by MEXT/JSPS KAKENHI
20H04166.