2

1 つのファイル内のコードの動きを検出するために git Blame -M を使用すると、自分では説明できない結果が得られます。

まず、次のファイル (file.cpp) をコミットします。

void func1(){return;}[CR][LF]
int func2(){return 23;}[CR][LF]

次に、最初の行にあったものを移動し、代わりに何か新しいものを追加して変更します。

float newFunc(){return 23.0;}[CR][LF]
int func2(){return 23;}[CR][LF]
[CR][LF]
[CR][LF]
void func1(){return;}[CR][LF]

ログは次のようになります。

>git log --oneline -2
18c670f modified file.cpp
92b4186 added file.cpp

今、私は責任を負います：

git blame -s -w -M file.cpp
18c670fa 1) float newFunc(){return 23.0;}
92b4186d 2) int func2(){return 23;}
18c670fa 3)
18c670fa 4)
18c670fa 5) void func1(){return;}

func1() を含む行が移動したと認識されないのはなぜでしょうか。必要な文字数を減らそうとしました (つまり、-M4 など)。さらに、 -w オプションがあるため、スペースは問題になりません。

4

1 に答える 1

1

（3年後）

func1()を含む行が移動したと認識されないのはなぜでしょうか。

これは、近日公開予定の git 2.10 で最近 (2016 年 7 月) に修正されたバグに関連している可能性があります。

David Kastrup ( )によるcommit 17a07e2 (2016 年 5 月 28 日)を参照してください。( 2016 年 7 月 19 日、コミット 7418a6bでJunio C Hamanoによってマージされました)fedelibre
gitster

blame: で移動した行を検索する際に、0 コンテキスト行が必要です-M

必要な 1 つのコンテキスト行のコア部分git blame -Mですが、コードには根拠がありません。そのスレッド「の動作を理解する」git blame -Mで説明されているようなアーティファクトが発生します。

関数diff_hunksはdiffエンジンのラッパーです。
コンテキストの長さをこのラッパーに明示的に入れると (関数で引数を渡さずにコンテキストの長さをゼロに設定するのではなく)、誰かがそれを別の値で呼び出すことを望んでいたことを明確に示します。

私が覚えている限り、ファイルにはドキュメントや理論的根拠はありません。
クラッシュしたり、無限ループに陥ったりする可能性があります。ある時点でそうすることができたかもしれませんが、もはやそうではありません。

役立つかどうかはわかりませんが、 d24bba8 ( : ファイル内の行の動きを非難する)ctxlen = 1に追加されているようです。git-pickaxe -M

単一行の動きを検出しないのは設計ごとのようで、ドキュメントだけではこれについて正確ではありません。このような機能強化は、機能要求と見なすことができますか?

このスレッドは、以前の選択の歴史にさらに光を当てます。

ゼロ以外のコンテキストが良いアイデアであると考えた理由をリモートで示唆する唯一のものは、これであり、その中で私は次のように述べました。

" " アルゴリズムによるコピー元の識別を改善するために、いくつかの周囲のコンテキスト行を使用する必要があるかもしれませんがciff、それは実装の細かい部分です。

于 2016-07-20T07:12:28.303 に答える