一般社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
社団法人 電子情報通信学会
INFORMATIONAND COMMUNICATION ENGINEERS

信学技報
IEICE Technical Report
信学技報
SS2021-2,KBSE2021-14(2021-07)

THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERSTECHNICAL REPORT OF IEICE.

複数ファイルの履歴を考慮した Git ファイル追跡精度改善の提案
前島葵†

肥後 芳樹†

楠本 真二†† 大阪大学大学院情報科学研究科〒 565-0871 大阪府吹田市山田丘 1-5
E-mail: †{a-maejim,higo,kusumoto}@ist.osaka-u.ac.jp
あらまし

Git に代表される版管理システムから得られるファイル変更履歴は，バグモジュールの検出や同時変更

コードの分析などマイニングソフトウェアリポジトリ（MSR）に関する様々な研究に役立てられている．そのため，変更履歴に誤りが存在すれば MSR の研究に影響を与えてしまう．本研究では，版管理システムとして広く用いられている Git を対象にファイル変更履歴の追跡精度の調査を行う．Git にはファイルの名前変更や移動を検出し，ファイルの変更を追跡する機能が備わっている．しかし，Git の追跡機能はファイルの追跡を個別に行うため，名前変更
時に複数ファイルの追跡結果が被ってしまう問題がある．そこで，Git の追跡ではどの程度変更履歴が被ってしまうのか調査を行い，より精度の高い追跡を目指した複数ファイルの変更を考慮する手法を提案する．オープンソースプ
ロジェクトに対する調査の結果，145 件の Java プロジェクトのうち 45 件のリポジトリにおいて変更履歴の被りが存在した．また，複数ファイルの変更を考慮することで追跡精度が 17%向上し提案手法が有効であることが示された．
キーワード ソフトウェアリポジトリマイニング，Git，バージョン管理システム

1. は じ め に
Git に代表されるバージョン管理システムは現在多くのソフのコマンドを用いることで，どのコミットで誰がどのファイ
ルにどのような変更を加えたかといった情報が容易に取得できる．

トウェア開発プロジェクトに利用されている．開発者は，バー

Git にはファイルの名前変更や移動を検出し，変更を追跡す

ジョン管理システムが提供する機能を用いることで，過去のる機能が備わっている．ファイル名が変更された時，以前のコ

任意のバージョンの状態に復元する，バージョン間の差分をミットに存在したファイルの中で最も類似度の高いファイル

確認する，複数の開発者が書いたコードを統合する等が容易

を変更前のファイルとして名前変更が行われたと見なす．しに行える．

かし，Git の追跡は同時に複数のファイルの変更を考慮せず，バージョン管理システムに記録される変更履歴には，開発

1 つのファイルを対象とした変更しか追跡しない．そのため，者と研究者の両者にとって有用な情報が豊富に含まれている．

個々には最適な追跡が行われていても，個々に得た変更履歴

開発者は，ソースコードがどのように進化したか理解するたをまとめ，全てのファイルの変更履歴を確認すると途中から

め，コードレビューやチーム開発での情報共有の情報源としファイルの変更履歴が被ってしまう問題が存在する．145 件のて変更履歴を利用する [1]〜[3]．研究者は，ソフトウェアリポ

Java オープンソースプロジェクトリポジトリに対して調査を

ジトリを解析し，蓄積された情報から有用な知見を見つけ将行なったところ，47 件のリポジトリにおいて名前変更による来のソフトウェア開発に活かすソフトウェアリポジトリマイ

変更履歴の被りが存在した．

ニングを行なっている．例えば，バージョン管理システムが本研究では，より精度の高いファイル追跡を目指し，複数提供する履歴を利用することで，バグを含む変更の予測や同ファイルの変更を考慮する手法を提案する．提案手法はオー時に変更される可能性の高いコードの予測を行う [4], [5]．

プンソースの Git クライアントである JGit を拡張し実装を行

ソフトウェア開発において変更の理解は重要であり，バーなった．名前変更による変更履歴の被りが存在した変更に対ジョン管理システムから得られる変更履歴は，ソースコード

して既存の Git と比較実験を行なった結果，既存の Git の追跡

理解のための重要な情報源として利用されている．そのため，の適合率 63%に対して，拡張後 JGit の適合率は 17%向上し，変更履歴に誤りが存在すればソフトウェアリポジトリマイニ

80%の適合率となった．

ングの研究に影響を与えてしまう．
ソフトウェア開発の過程では，多くの変更が加えられる．

2. 研 究 動 機

ソースコードの変更には、単一のコードを書き換える簡単な変オープンソースプロジェクトである OpenReﬁne における更から，ファイル全体に影響を及ぼすクラス名の変更やパッ例を示す．図 1 は，“git log –-follow” コマンドを，ファイ

ケージの移動など複雑な変更まで存在する．バージョン管理

ル “ReconMarkNewTopicsOperation.java” と “ReconDiscard-

システムではソースコードはファイル単位で管理される．Git

JudgmentsOperation.java” に対して実行した結果である．Git-7—1—
This article is a technical report without peer review, and its polished and/or extended version may be published elsewhere.
Copyright ©2021 by IEICE

$ git log --follow --name-status --oneline./main/src/com/google/refine/operations/recon/ReconMarkNewTopicsOperation.java
e4e73d0b9 M main/src/com/google/refine/operations/recon/ReconMarkNewTopicsOperation.java...
c98a8ad55 R095 src/main/java/com/metaweb/gridworks/model/operations/ReconMarkNewTopicsOperation.java
src/main/java/com/metaweb/gridworks/operations/ReconMarkNewTopicsOperation.java
1227c9dff R068 src/main/java/com/metaweb/gridworks/model/operations/ApproveNewReconOperation.java
src/main/java/com/metaweb/gridworks/model/operations/ReconMarkNewTopicsOperation.java
4b2e48614 M src/main/java/com/metaweb/gridworks/model/operations/ApproveNewReconOperation.java
604dd53eb M src/main/java/com/metaweb/gridworks/model/operations/ApproveNewReconOperation.java
8c41af9c1 M src/main/java/com/metaweb/gridworks/model/operations/ApproveNewReconOperation.java...
bacb71ab6 A src/main/java/com/metaweb/gridworks/model/operations/ApproveNewReconOperation.java(a) ReconMarkNewTopicsOperation.java の変更履歴$ git log --follow --name-status –-oneline./main/src/com/google/refine/operations/recon/ReconDiscardJudgmentsOperation.java
e4e73d0b9 M main/src/com/google/refine/operations/recon/ReconDiscardJudgmentsOperation.java...
c98a8ad55 R095 src/main/java/com/metaweb/gridworks/model/operations/ReconDiscardJudgmentsOperation.java
src/main/java/com/metaweb/gridworks/operations/ReconDiscardJudgmentsOperation.java
1227c9dff R056 src/main/java/com/metaweb/gridworks/model/operations/ApproveNewReconOperation.java
src/main/java/com/metaweb/gridworks/model/operations/ReconDiscardJudgmentsOperation.java
4b2e48614 M src/main/java/com/metaweb/gridworks/model/operations/ApproveNewReconOperation.java
604dd53eb M src/main/java/com/metaweb/gridworks/model/operations/ApproveNewReconOperation.java
8c41af9c1 M src/main/java/com/metaweb/gridworks/model/operations/ApproveNewReconOperation.java...
bacb71ab6 A src/main/java/com/metaweb/gridworks/model/operations/ApproveNewReconOperation.java(b) ReconDiscardJudgmentsOperation.java の変更履歴

図 1 名前変更によって変更履歴が被る例$ jgit log --follow --name-status –-oneline./main/src/com/google/refine/operations/recon/ReconDiscardJudgmentsOperation.java
e4e73d0b9 M main/src/com/google/refine/operations/recon/ReconDiscardJudgmentsOperation.java...
c98a8ad55 R098 src/main/java/com/metaweb/gridworks/model/operations/ReconDiscardJudgmentsOperation.java
src/main/java/com/metaweb/gridworks/operations/ReconDiscardJudgmentsOperation.java
1227c9dff R057 src/main/java/com/metaweb/gridworks/model/operations/DiscardReconOperation.java
src/main/java/com/metaweb/gridworks/model/operations/ReconDiscardJudgmentsOperation.java
4b2e48614 M src/main/java/com/metaweb/gridworks/model/operations/DiscardReconOperation.java
604dd53eb M src/main/java/com/metaweb/gridworks/model/operations/DiscardReconOperation.java
8c41af9c1 M src/main/java/com/metaweb/gridworks/model/operations/DiscardReconOperation.java...
bacb71ab6 A src/main/java/com/metaweb/gridworks/model/operations/DiscardReconOperation.java

図 2 提案手法による改善結果

有効に働いている．

によって追跡を行った結果，“ReconMarkNewTopicsOperation.java” はコミット 1227c9dﬀ で “ApproveNewReconOpera-

3. 予 備 調 査

tion.java” から名前変更が行われいる．また，“ReconDiscard-

まず初めに，実際のソフトウェアリポジトリ中にはどの程

JudgmentsOperation.java” も同様に，コミット 1227c9dﬀ で度変更履歴の被りが存在するか調査を行なった．

“ApproveNewReconOperation.java” から名前変更が行われい

調査対象

る．個別に得られた 2 つのファイルの変更履歴を合わせると，

3. 1

共にコミット 1227c9dﬀ 以前の変更履歴が被ってしまっている

Borges らのデータセット [6] を使用し，GitHub に存在する

ことがわかる．しかし実際には，“ReconDiscardJudgmentsOp-

スター数上位のオープンソースプロジェクトを調査対象とし

eration.java” は “ApproveNewReconOperation.java” からの名

た．Borges データセットには，GitHub におけるスター数上

前変更ではなく，“DiscardReconOperation.java” からの名前

位 2,279 のプロジェクトが含まれる．その中から，Java プロ
ジェクトと分類される 202 件のプロジェクトのうち 2021 年 5

変更である．
これらの二つのファイルは共に共通した親クラスを持つた

月に GitHub 上にリポジトリが存在した 197 件のプロジェク

めソースコードの内容が似通っていた．Git のアルゴリズムでトを対象とした．さらに，テストコードを除き Java ファイルは対象とするファイル 1 つに対して，類似度が最も高いファを 2 つ以上持つプロジェクト 145 件を調査対象とした．図 3

イルを選び追跡を行う．そのため，個別には最適な追跡がでには調査対象とした 145 件のプロジェクトについて，コミッ

きているように見えても，2 つのファイルに対しての変更履歴

ト数と Java ファイル数の分布を示している．分布からわかを合わせると途中から同じファイルを追跡してしまっていた．

る通り，様々な規模のプロジェクトを本研究では調査対象と提案手法では，単に最も類似度の高い追加，削除ファイル間した．Java ファイル数の規模が大きなプロジェクトは順に，を名前変更と見なすのではなく，変更が行われた全てのファ

elasticsearch が 9,201 ファイル，gradle が 8,624 ファイルであイル間の類似度を考慮することで誤った追跡を防ぐ．上述しる．また，コミット数の規模が大きなプロジェクトは順に，た状況において，提案手法を “ReconDiscardJudgmentsOper-platform_frameworks_base が 560,597 件，intellij-community

ation.java” に対して実行した結果が図 2 であり，提案手法がが 302,536 件であった．

-8-

—2—

10K

リネームによる履歴の被りが存在したファイル数

1K

Javaファイル数

1K

100

10

100

10

1
1

1

10

100

1K

10K

100K

1K

10K

1K

調査対象プロジェクト規模

リネームによる履歴の被りが存在したファイル数

図3

調査方法

調査対象プロジェクトに存在する Java ファイルに対してMaster の最新コミットを起点に “git log –-follow [file]”
コマンドを実行し，変更履歴を得た．変更履歴を分析し，同一のコミットにおいて名前変更前ファイルが被っているファイルを抽出した．
3. 3

100(a) Java ファイル数に対しての被りファイル数

1M

コミット数

3. 2

10

Javaファイル数

1

調査結果

図 3 に示した調査対象プロジェクトの中で，赤い点は名前変
更による変更履歴の被りが存在したプロジェクトの分布を示

100

10

1
1

している．調査対象プロジェクト 145 件に対して，変更履歴の

10

100

1K

10K

100K

1M

コミット数

被りを持つプロジェクトは 47 件 (32%) 存在した．また，Java(b) コミット数に対しての被りファイル数

ファイル数が 10 以上のプロジェクトに対象を絞ると，126 件

図4

名前変更による変更履歴の被り数

中の 47 件 (37%) である．Java ファイル数が 100 以上のプロ

4. 提 案 手 法

ジェクトに対象を絞ると，63 件中の 41 件 (65%) である．Java
ファイル数が 1000 以上のプロジェクトに対象を絞ると，19 件

本研究では，ファイルのより高精度な追跡を目指し複数ファ中の 17 件 (89%) である．コミット数や Java ファイル数が少イルの変更を考慮する手法を提案する．提案手法は以下の Step

ないプロジェクトでは履歴の被りが発生せず，プロジェクトからなる．図 5 に提案手法の概要を示す．提案手法の入力はの規模が大きいほど履歴の被りが存在し易い結果になった．

追加ファイル群と削除ファイル群である．提案手法は，入力

図 4 に Java ファイルに対する名前変更による変更履歴の被として与えられた各追加ファイルについて，十分に類似したり数，コミット数に対しての名前変更による変更履歴の被りが削除ファイルが見つかった場合にはそれらを対応づけること存在したファイル数を示す．変更履歴の被りが存在したファによりファイル名が変更されたと見なす．類似した削除ファ

イル数が多いプロジェクトは順に，8,624 ファイルに対してイルが見つからなかった場合にはそのファイルは真に追加さ2.6%の 224 ファイルに被りが存在した gradle，3,447 ファイルに対して 5.8%の 199 ファイルに被りが存在した spring-boot，
3,807 ファイルに対して，2.3%の 87 ファイルの被りが存在しれたと見なす．以下の Step は，Java ファイルが追加および削除された各コミットに対して実行される．
Step-1 追加ファイルと削除ファイルの全てのペアに対して，

た neo4j である．変更履歴の被りが存在した割合が多いプロ

それらファイル間の類似度を計算．

ジェクトは順に，15 ファイルに対して 20.0%の 3 ファイルに

Step-2 追加削除ファイルのペアを類似度の降順に整列．

被りが存在した otto，153 ファイルに対して 10.5%の被りが存

Step-3 整列した各ペアについて，類似度の降順に以下の処在した retroﬁt である．

理を行う．そのペアに含まれる削除ファイルが他の追加ファ

図 4 に示される通りプロジェクトの規模 Java ファイル数とイルの名前変更と見なされていない場合には，その削除ファイ

変更履歴の被りには相関があり，規模が大きなプロジェクト

ルを現在のペアである追加ファイルの名前変更と見なす．すほど大規模な名前変更やパッケージの移動が起こり易いため

でにその削除ファイルが他の追加ファイルの名前変更と見な

変更履歴が被りやすい結果になった．

されている場合には，そのペアについてはなにもしない．

-9-

—3—

⼊⼒

追加ファイル群

削除ファイル群

A.java B.java C.java D.java

E.java F.java G.java

A.java A.java A.java B.java B.java B.java C.java C.java C.java D.java D.java D.java

Step-1 全ペア類似度を計算

95%

70%

65%

90%

88%

40%

85%

60%

45%

65%

40%

30%

E.java F.java G.java E.java F.java G.java E.java F.java G.java E.java F.java G.java

Step-2 類似度50%以上ペアを降順に整列A.java B.java B.java C.java A.java A.java D.java C.java C.java B.java D.java D.java
95%

90%

88%

85%

70%

65%

65%

60%

45%

45%

40%

30%

E.java E.java F.java E.java F.java G.java E.java F.java G.java G.java F.java G.java

A.java B.java B.java C.java A.java A.java D.java C.java C.java B.java D.java D.java

Step-3 名前変更か判定

95%

90%

88%

85%

70%

65%

65%

60%

45%

45%

40%

30%

E.java E.java F.java E.java F.java G.java E.java F.java G.java G.java F.java G.java

A.java B.java B.java C.java A.java A.java D.java C.java C.java B.java D.java D.java

Step-4 コピーか判定

95%

90%

88%

85%

70%

65%

65%

60%

45%

45%

40%

30%

E.java E.java F.java E.java F.java G.java E.java F.java G.java G.java F.java G.java

A.java B.java B.java C.java A.java A.java D.java C.java C.java B.java D.java D.java D.java

Step-5 追加か判定

95%

90%

88%

85%

70%

65%

65%

60%

45%

45%

40%

30%

E.java E.java F.java E.java F.java G.java E.java F.java G.java G.java F.java G.java

A.java B.java

出⼒

名前変更

95%

C.javaコピー

88%E.java F.java

D.java追加

85%

E.java

図 5 提案手法の概要

どの削除ファイルとも名前変更と見なされなかった追加ファ

0

Step-5 どの削除ファイルとも名前変更もしくはコピーと見なされていない追加ファイルについては，真に追加されたファイルであると見なす．
以降，各 Step について説明する．Step-1 では，追跡対象であるファイルと削除された各ファイル間の類似度だけでなく，追加された各ファイルと削除された各ファイルの全てのペアについて類似度を計算する．JGit ではファイルの名前変更は，ファイルの内容の類似度とファイルパスの類似度の二つを利用して判断される．従来の JGit では，ファイルパスの類似度
はパス全体の文字列の一致度であるが，提案手法では，ファイルパスの類似度をレーベンシュタイン距離を用いて行うように変更した．また，名前変更と見なす類似度のしきい値は Gitのデフォルト値である 50%とした．
Step-2 では，類似度の高いファイルペアから名前変更と見なすために，追加削除ファイルのペアを類似度の降順に整列す
る．Step-3 では，整列した各ペアについて，類似度の降順に以下の処理を行い名前変更ファイルペアを決定する．そのペアに含まれる削除ファイルが他の追加ファイルの名前変更と見

5

10

15

20

25

30

35 (%)

図 6 名前変更ペアに対するコピーの類似度差

イルについては，もっとも類似度が高い削除ファイルのコピーであると見なす．

+

COPY

Step-4 しきい値よりも類似度の高い削除ファイルを持つが，なされていない場合には，その削除ファイルを現在のペアである追加ファイルの名前変更と見なす．すでにその削除ファイ
ルが他の追加ファイルの名前変更と見なされている場合には，そのペアについてはなにもしない．Step-4 では，コピーの判定を行う．名前変更のペアが決定しなかった追加ファイルはしきい値よりも高い類似度を持つ削除ファイルが存在した場合に，その中で最も類似度が高い削除ファイルのコピーと見なす．この時，低い類似度のファイルが誤って追跡されることを防ぐため，名前変更ファイル間の類似度に対して 15%以上類似度差があるファイルはコピーと見なさない．例えば，追加ファイル“RenameA.java” と削除ファイル “A.java” が 90%で名前変更と見なされたとする．別の追加ファイルである “CopyA.java”と削除ファイル “A.java” の類似度が 80%であるならば，名前変更ペアに対しての類似度差は 10%である．この場合，類似度
差が 15%以内のためコピーと見なす．図 6 に目視結果によってファイルのコピーであると見なした 63 の Java ファイルについて，名前変更ファイルペアに対する類似度差を示している．図 6 から本研究では正しいコピーを 75%程度含める 15%を閾値に採用した．

- 10 -—4—

commit 2752370baf5f1b928805f8fb4312afe3703fb740
R076
subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/repositories/layout/PatternRepositoryLayout.java
subprojects/dependencymanagement/src/main/java/org/gradle/api/internal/artifacts/repositories/layout/DefaultIvyPatternRepositoryLayout.java-public class PatternRepositoryLayout extends RepositoryLayout {+public class DefaultIvyPatternRepositoryLayout extends AbstractRepositoryLayout implements IvyPatternRepositoryLayout {private final Set<String> artifactPatterns = new LinkedHashSet<String>();private final Set<String> ivyPatterns = new LinkedHashSet<String>();/*** Adds an Ivy artifact pattern to define where artifacts are located in this repository.
* @param pattern The ivy pattern+* {@inheritDoc}*/
public void artifact(String pattern) {artifactPatterns.add(pattern);}....

(a) DefaultIvyPatternRepositoryLayout.java

commit 2752370baf5f1b928805f8fb4312afe3703fb740
R054
subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/repositories/layout/PatternRepositoryLayout.java
subprojects/core/src/main/groovy/org/gradle/api/artifacts/repositories/IvyPatternRepositoryLayout.java-public class PatternRepositoryLayout extends RepositoryLayout {private final Set<String> artifactPatterns = new LinkedHashSet<String>();private final Set<String> ivyPatterns = new LinkedHashSet<String>();private boolean m2compatible;+public interface IvyPatternRepositoryLayout extends RepositoryLayout {

+
....

/**
* Adds an Ivy artifact pattern to define where artifacts are located in this repository.
* @param pattern The ivy pattern*/public void artifact(String pattern) {artifactPatterns.add(pattern);}
void artifact(String pattern);(b) IvyPatternRepositoryLayout.java

図 7 gradle における履歴の被り例

おける追跡の正解数とその割合を示している．名前変更全体の5. 評 価 実 験
5. 1

57.3%は Git，拡張後 JGit で共に正しく追跡し，全体の 14.6%
は Git，拡張後 JGit で共に誤った追跡を行なった．

実験概要

本実験の目的は，既存の Git と拡張後の JGit の変更履歴を

6. 考

比較し，どの程度適合率が向上するか調査することである．
Git において変更履歴の被りが存在したファイルに対して，拡張後 JGit を利用し変更履歴の追跡を行う．

察

本章では 5. で述べた評価実験についての考察を行う．追加
ファイルと削除ファイルの全てのペアを考慮することで追跡得られた Git,JGit の結果に対して，名前変更による変更履
歴の被りが発生した変更前後のソースコードの目視確認を行

適合率の向上が見られた例，向上が見られなかった例について考察する．

い，名前変更が正しいかどうか確認を行なった．この時，目視

図 7 に追跡適合率の向上が見られた例を示す．図 7 にによって正しく追跡できていると判定できた割合を適合率とオープンソースプロジェクトである gradle において，従来する．

の Git で変更履歴が被ってしまった 2 つの Java ファイルを

5. 2

実験対象

示す．‘DefaultIvyPatternRepositoryLayout.java” と ‘IvyPat-

3. で述べた予備実験において名前変更による変更履歴の被

ternRepositoryLayout.java” はそれぞれ 76%，54%の類似度にりが存在した 47 件のオープンソース Java プロジェクトにおよって共に ‘PatternRepositoryLayout.java” からの名前変更とける 677 の Java ファイルを実験対象とした．

見なされている．拡張後の JGit では前者の追跡のみを行い，

5. 3

実験結果

後者の追跡は行わないため低い類似度のファイルを名前変更

表 1 に Git，拡張後の JGit が正しく追跡できたファイル数と見なしていた誤検出の削減に成功した．このプロジェクトとその割合を示す．Git の追跡の適合率が 63%に対して，拡張に含まれる全ての Java ファイルには Apache ライセンスに関後は 17%適合率が向上し，適合率は 80%となった．また，表 2する条文が含まれており，その存在が関係ない削除ファイルとに 3 ファイル以上被りが存在した変更に対象を限定し，適合追加ファイル間の類似度を高くしていたため，従来の Git では率を示す．多くのファイルの変更が被ってしまった複雑なコ
ミットに対しても，21%適合率が向上し提案手法が有効であるとわかった．
表 3 に 677 の Java ファイルについて，Git，拡張後 JGit に
表1 適
名前変更全体Git の適合率合

表 2 適合率（3 ファイル以上被りが存在した変更）
名前変更全体191

Git の適合率

99 ( 51%)

拡張後 jGit の適合率 139( 72%)
表 3 追跡の正誤数とその割合率
677426( 63%)

拡張後 jGit の適合率 542( 80%)

- 11 -

Git で正しく追跡

Git で誤った追跡

jGit で正しく追跡388(57.3%)

151(22.3%)

jGit で誤った追跡

39 ( 5.8%)

99 (14.6%)—5—

$ git log –p –U100 –follow client/src/main/java/org/asynchttpclient/netty/channel/TransportFactory.java
commit 1e1a84409e551d8455faa9595c09b56d46e63f74
R067 client/src/main/java/org/asynchttpclient/netty/channel/NioSocketChannelFactory.javaclient/src/main/java/org/asynchttpclient/netty/channel/TransportFactory.java/*- * Copyright (c) 2016 AsyncHttpClient Project. All rights reserved.
+ * Copyright (c) 2019 AsyncHttpClient Project. All rights reserved.
** This program is licensed to you under the Apache License Version 2.0,
* and you may not use this file except in compliance with the Apache License Version 2.0.
* You may obtain a copy of the Apache License Version 2.0 at*
http://www.apache.org/licenses/LICENSE-2.0.
** Unless required by applicable law or agreed to in writing,* software distributed under the Apache License Version 2.0 is distributed on an* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the Apache License Version 2.0 for the specific language governing permissions and limitations there under.
*/
package org.asynchttpclient.netty.channel;+import io.netty.channel.Channel;
import io.netty.channel.ChannelFactory;-import io.netty.channel.socket.nio.NioSocketChannel;+import io.netty.channel.EventLoopGroup;-enum NioSocketChannelFactory implements ChannelFactory<NioSocketChannel> {+import java.util.concurrent.ThreadFactory;- INSTANCE;+public interface TransportFactory<C extends Channel, L extends EventLoopGroup> extends ChannelFactory<C> {++ L newEventLoopGroup(int ioThreadsCount, ThreadFactory threadFactory);-@Override
public NioSocketChannel newChannel() {return new NioSocketChannel();}}

図 8 async-http-client の例

誤って名前変更と見なしてしまっていた．提案手法では，全おいて名前変更による変更履歴の被りが存在した．また，ファての削除追加ファイルのペアに対して類似度を算出するため，

イル数やコミット数の規模が大きなプロジェクトほど，変更関係ないファイル間の類似度がたとえしきい値以上となって履歴の被りが発生し易いことがわかった．

しまっても，本来名前変更と見なされるべきファイルのペア

本研究では，より精度の高いファイル追跡を目指し複数ファの類似度がそれ以上に高くなるために正しく名前変更と見なイルの変更を考慮する手法を提案した．提案手法はオープン

すことができた．

ソースの Git クライアントである JGit を拡張し実装を行なっ

しかし，提案手法でも正しく追跡できなかった名前変更も存た．名前変更による変更履歴の被りが存在した変更に対して在した．図 8 に追跡適合率の向上が見られなかった例を示す．

既存の Git と比較実験を行なった結果，既存の Git の追跡の適

図 8 にオープンソースプロジェクトであるに async-http-client

合率 63%に対して，拡張後 JGit の適合率は 17%向上し，80%

おいて，誤って名前変更と見なされた変更の例を示す．誤っての適合率となった．

追跡を行なった原因は，ファイル行数の少なさによる類似度

今後の課題として，ソフトウェアリポジトリマイニングのの精度不足であった．ファイル全体に対し，ライセンスに関研究において精度の高い追跡を行うことで，既存の実験結果する条文などプロジェクト全体に共通で多く含まれる部分のが変わることがないか調査する予定である．
文

割合が高い場合は，類似度が高く算出されてしまう．図 8 はファイルの全行数 26 行のうち，コメント部分が半数の 13 行

[1]を占めている．そのため，関連のない変更がなされても類似度が 67%と高く算出された．この問題に対しては，コメントなどプロジェクト全体における共通部分を除いた類似度の算[2]出ができれば解決できると考える．
[3]

7. 妥当性への脅威
内部的妥当性に対する脅威は，目視確認に関する評価であ[4]

る．精度の調査での判定は，目視を行なった著者らの主観に依存している．この脅威は，データの一部に対して目視確認
を二人以上で行い，合意を得ることで軽減した．

[5]

8. お わ り に[6]

本研究では，オープンソース Java プロジェクトにおける名
前変更による変更履歴の被りについて調査を行なった．調査の結果，145 件のリポジトリ中，32%の 47 件のリポジトリに- 12 -

献

K. Maruyama, E.Kitsu, T.Omori, and S.Hayashi, “Slicing
and replaying code change history,” Proc. IEEE/ACM International Conference on Automated Software Engineering,p.246–249, 2012.
O. Kononenko, O. Baysal, and M.W. Godfrey, “Code review
quality: How developers see it,” Proc. International Conference on Software Engineering, p.1028–1038, 2016.
A.J. Ko, R. DeLine, and G. Venolia, “Information needs incollocated software development teams,” Proc. International
Conference on Software Engineering, p.344–353, 2007.
T. Zimmermann, P. Weisgerber, S. Diehl, and A. Zeller,“Mining version histories to guide software changes,”
Proc. International Conference on Software Engineering,p.563–572, 2004.
N. Nagappan and T. Ball, “Use of relative code churn measures to predict system defect density,” Proce. International
Conference on Software Engineering, pp.284–292, 2005.
H. Borges, A. Hora, and M.T. Valente, “Understanding thefactors that impact the popularity of github repositories,”
Proc. IEEE International Conference on Software Maintenance and Evolution, pp.334–344, 2016.

—6—