9

svn クライアントとして git-svn を使用しています。時々、次の問題に遭遇します。

  1. ローカルの git ブランチでいくつかのコミット、空のステージ、クリーンな作業コピーから始めます。

  2. Windows のコマンド ラインに「git svn rebase」と入力して、チームの変更を取得し、それらの後にコミットを配置して、線形の履歴を保持します (これは git-svn を使用するために必要です)。

  3. すべてがうまくいき、チームのコンテンツが取得され、その後コミットがリベースされますが...

    最終的に作業コピーが変更され、ステージでファイルが変更されます。作業コピーの変更は、ステージでの変更とは正反対です。

私は通常、ステージにあるすべてのものをステージング解除することでこれを回避します。これにより、作業コピーの変更が元に戻りますが、これは問題ありませんが、ここで何が起こっているのかを本当に理解したいと思います.

質問: それはバグですか、それとも git rebase で理解できないものですか?

注：後で「git svn fetch」と「git rebase」を使用しているときに問題が発生しました。

注: 私は大きな svn リポジトリ (10000 以上のファイル、150000 以上のリビジョン) を持つ Windows で git を使用しており、git-extensions も使用しています。編集：私はそれをリポジトリを探索してコミットするだけに使用します。Windowsコマンドラインから他のことをします。

編集：コメントの1つで要求されたように、問題を理解するのに役立つ2つのスクリーンショットを次に示します。1 つ目は作業コピーの内容で、2 つ目はステージの内容です。両方が正反対であることが簡単にわかります。

作業コピー: ここに画像の説明を入力

ステージ (作業コピーの変更を元に戻す、非常に視覚的: 同じ画像、赤と緑が入れ替わる): ここに画像の説明を入力

編集:非常に単純なケースで問題を再現しました:私のコミットは1つのファイルのみを変更し、「git svn rebase」中にフェッチされた新しいコミットはほとんどなく、変更されたファイルには影響しませんでした。「gitk --all」で確認しました。git-extensions や "git status" とまったく同じことを言っています。これが gitk の出力です。下から上に見ていきます。

  • 最後の 3 行は、リベース時にフェッチされた 3 つのコミットです。それらのどれも私のファイルに触れません。
  • 上から 3 行目は、リベース後の私のコミットを示しています。すべて問題ありません。追加すべきものを追加し、削除すべきものを削除します。
  • 2 行目はインデックスの内容を示しています。コミットを元に戻す変更が含まれています。
  • 最初の行は、作業コピーの内容を示しています。これには、私のコミットと同じ変更が含まれており、IE はインデックスの変更を元に戻します。

ここに画像の説明を入力

編集：.git問題が発生した「git svn rebase」後の私のディレクトリの内容は次のとおりです。

17/02/2012  04:57                 0 ArmuazEm5Z
05/04/2012  02:28                 0 BeMzRLwWcu
06/11/2012  14:37                90 COMMIT_EDITMSG
01/11/2012  15:42               628 config
15/02/2012  04:21                73 description
16/02/2012  13:22                 0 fuMhUevkYu
05/11/2012  15:53         1 703 279 gitk.cache
05/07/2012  03:49                 0 gJfUbdRuG9
06/11/2012  14:42                23 HEAD
11/07/2012  03:14    <DIR>          hooks
21/02/2012  03:22                 0 II5HPacSJd
06/11/2012  14:42         5 439 960 index
15/10/2012  13:18    <DIR>          info
16/02/2012  08:16                 0 jerS1GtBYS
17/02/2012  04:57                 0 Kg64sq9pzS
15/02/2012  23:36                 0 lbe0yALJYy
15/10/2012  13:17    <DIR>          logs
19/10/2012  16:58    <DIR>          objects
06/11/2012  14:42                41 ORIG_HEAD
25/10/2012  11:02             2 795 packed-refs
05/07/2012  03:49                 0 PpxYa5z0Hc
02/11/2012  10:00    <DIR>          refs
15/02/2012  23:36                 0 sm6ociDGGF
06/11/2012  14:42    <DIR>          svn
21/02/2012  03:22                 0 vEqtL0Yiqd
05/04/2012  02:28                 0 VFwn3laTEV
16/02/2012  13:22                 0 XYoiLqY5BM
16/02/2012  08:16                 0 z9vL8lRT7t
              22 File(s)      7 146 889 bytes
               6 Dir(s)  54 105 219 072 bytes free

編集:この問題を追跡することに興味がある場合は、git@vger.kernel.org メーリング リストに「[git-svn] [バグ レポート] git svn rebase 後にインデックスが奇妙な状態になる」という件名でバグを報告しました。

4

1 に答える 1

3

これはバグのようです。リベースの前に作業ディレクトリとインデックスがクリーンである場合、リベース後にクリーンである必要があります。または、マージの競合が発生し、それをクリーンアップしてリベースを続行する機会が得られるはずです。

何らかの理由で、ローカルの変更を適用した後、インデックスが古いままになっているようです。

基本的に、リポジトリの現在の状態には 3 つの主なビューがあります。HEAD コミットがあります。これは、最後のコミット時点でのリポジトリの状態であり、次のコミットはその子になります。これは、リベース中に適切に更新されています。HEAD はローカル コミットになり、アップストリーム リポジトリから取得したものに基づいてリベースされます。

次のコミットの状態がどうなるかのビューを含むはずのインデックスがあります。ここが問題のようです。クリーン ツリーからのリベースが成功した後、インデックスは HEAD と同じリポジトリ ビューを持っているように見えますが、アップストリーム リポジトリに含まれているものの古いビューを取得しているように見えます。アップストリーム リポジトリの上にローカル パッチを適用した後、更新されていないようです。

そして、作業コピーがあります。ディスク上の実際のファイル。なぜかリベースをしていると、ヘッドコミットはちゃんと更新されており、ワーキングツリーもちゃんと更新されている（もしくは放置されている）のですが、インデックスは元のコミットを参照している状態のままです。あなたはにリベースしています。これは、インデックスをリベースされたコミットと比較すると、変更を元に戻したように見え、作業コピーをインデックスと比較すると、それらを再度追加したように見えることを意味します。

いくつかの確認事項:

  1. .gitこのような問題のあるリベース後のディレクトリの内容を見せていただけますか? の最上位にあるファイルのリストだけ.gitでも役に立ちます。実際には、ファイル名、変更日、権限を含む完全なリストから、もう少し詳しい情報が得られる場合があります。
  2. ネットワークに接続されたファイルシステムでこれを使用していますか、それとも何か変わっていますか? ネットワーク化されたファイルシステムには、ファイルが古くなるという問題がある場合があります。それがあなたに起こっているのだろうか。
  3. 使用している Git のバージョンは何ですか?
于 2012-11-05T21:21:22.657 に答える