0

単一の git 呼び出しで連続していない行の行情報を取得するために、複数の -L オプションを指定して git Blame -L を実行しています。

私はこの呼び出しを信じていました:

git blame -L38,38 -L40,40 <file>

別々に行われたこれら 2 つの呼び出しと同等である必要があります。

git blame -L38,38 <file>
git blame -L40,40 <file>

ただし、複数の -L オプションを使用すると、38 行目と 40 行目ではなく、実際には 38 行目と 39 行目が返されるという 1 つのケースに遭遇しました。

$ git blame -L38,38 -L40,40 <file>
b6543ffe (Some Body 2015-11-24 15:15:03 -0500 38)           SOME CODE
b6543ffe (Some Body 2015-11-24 15:15:03 -0500 39)           SOME OTHER CODE

-L40,40 が 1 つしかない場合、git は実際には 40 行目を正しく返します。

$ git blame -L40,40 <file>
b6543ffe259 (Some Body 2015-11-24 15:15:03 -0500 40)                SOME CODE

-L が実際にどのように機能するかについて私が見逃しているものはありますか、それとも git のバグですか?

git バージョン 2.7.0.windows.1 と 2.11.0.windows.1 の両方を使用してみました。

4

1 に答える 1

0

必要があります ( 2013 年のこのパッチ シリーズでどのように実装されたかを確認できます) 。

しかし、明らかにそうではありません (おそらくバグです)。これにより、複数の行範囲の git Blameを修正する
ようなプロジェクトが導かれます。isaacbernat/pycrastinate

この修正により、各行に対して個別に git Blame が呼び出されます。

2020年8月更新

Git 2.29 (2020 年第 4 四半期) より前では、複数のターゲット行範囲が指定された場合、「( man )」は元の行のグループを合体させようとしすぎて、誤った結果を示していましたが、これは修正されました。git blame -La,b -Lc,d

commit c2ebaa2、commit dd7c611、commit 6dbf0c7 (2020 年 8 月 13 日) by Jeff King ( peff)を参照してください。
( 2020 年 8 月 19 日、コミット 93121dfでJunio C Hamanoによってマージされました)gitster

blame: 結果で隣接している行のみを結合します

報告者: Nuthan Munaiah
署名者: Jeff King

非難が終了した後、出力を生成する前に、元の容疑者で隣接していた行のグループを結合します (中間のコミットで行によって分割され、離れた可能性があります)。

ただし、行が結果で隣接していない場合、これにより誤った出力が発生する可能性があります。
たとえば、t8003 のケースには次のようなものがあります。

ABC
DEF

なる

ABC
SPLIT
DEF

結果の行 1 と 3 のみを非難すると、元の行で隣接していた 2 つの非難グループ (各行に 1 つ) が生成されます。
それらを 1 つのグループにまとめるにはこれで十分ですが、情報が失われます。出力ルーチンは、それらが結果でも隣接していると想定し、次のように出力します。

<oid> 1) ABC
<oid> 2) SPLIT

これは、次の 2 つの理由からナンセンスです。

  • 2行目ではなく3行目について質問されました。SPLIT 行をまったく出力すべきではありません
  • commit<oid>は SPLIT 行にまったく触れていません!
    行 3 の正しい原因が見つかりましたが、バグは実際には出力段階にあり、最終的なファイルから間違った行番号と内容が表示されています。

これは、疑わしい行と結果の行の両方が隣接している場合にのみ合体することで修正できます。これにより、このバグは修正されますが、合体が必要な場合は合体し続けます (たとえば、t8003 の既存のテストでは SPLIT がなくなり、行が結果で実際に隣接しています)。

于 2016-12-03T01:30:59.160 に答える