2

よし、契約だ。
Debian (lenny) リモート サーバーに Git をインストールしました。Git のバージョンは 1.5.6.5 です。リモートの共有/バックアップ リポジトリとして使用する予定です。
私の開発マシンは Windows を実行しており、ここで EGit を使用した Eclipse を実行しています。だから、これは私がやったことです:

  • git の共有ユーザーを作成しました。
  • SSH のセットアップ (Eclipse およびサーバー上)、公開鍵の交換など、すべてうまくいきました。
  • リモートリポジトリを作成し、git --bare initで初期化しました。
  • ローカル リポジトリにプロジェクトを作成し、いくつかの変更とコミットを行い、成功しました。
  • マスター ブランチをローカル リポジトリからリモート マスターにプッシュしました。ここまでは順調ですね。
  • (さらに、3 台目のマシンで、(EGit インポートを介して) リモート リポジトリを問題なく複製しました。)

リモートにプッシュされた最後のスナップショットにはすべてのファイルがあったため、プロジェクトからいくつかのファイルを削除し、コミットしてから、削除されたアイテムを復元することを期待してリモートからプルしようとしたときに、「奇妙な」ことが始まりました。pullは基本的にfetch + mergeであるため、EGit にはマージ戦略に関する既知の問題がいくつかあるようです。それにもかかわらず、フェッチを構成した結果、フェッチ仕様は次のようになりました。

refs/heads/master:refs/remotes/amrtest1/master

Fetch は正常に完了しました。少なくともそう思われました。リモート マスター ブランチのローカル リポジトリに新しいフォルダーが作成され、FETCH_HEAD もそこにあることに気付きました。
チェックアウトしたローカル マスター ブランチで、リモート マスターとのマージを試みました...結果は次のとおりです。

  • ローカルで削除されたファイルは復元されませんでした。
  • 同期パースペクティブで、不足しているファイルを確認できました (発信モードで?)
  • EGit の履歴ビューでは、フェッチのアクションは時系列でローカル コミットの(ファイルの削除後) であり、これは確かに正しくありません。

ここで何か間違ったことをしていますか?説明されているプロセスに基づいて、状態を復元するという私の期待は無効ですか? もしそうなら、どうすればよいでしょうか(リモートレポから状態を復元するか、少なくとも既存のローカルと正しくマージするため)?

ありがとう。

4

1 に答える 1

2

はい、あなたの期待は間違っています。実際、マージ操作中に明示的に削除したファイルを削除して復元したくないことをGitが何らかの形で精神的に検出すると信じていることを理解するまでに、何度か読み直しました。ファイルを元に戻したい場合は、それらを削除したコミットを元に戻すか、ファイルが存在するバージョンから現在のバージョンにファイルをコピーする必要があります。

その上、「EGit の履歴ビュー」と呼んでいるものについて正しい場合は、おそらくマージではなくリベースを実行するようにプルを設定したことを意味します。リベースでは、最後のプル以降の変更がアップストリームの現在のバージョンに対して適用されるべきであると大まかに想定されています。これは多くの場合、他の人にとってはわかりやすいですが、多くの人が同じコードまたは関連するコードを変更している場合、混乱したり完全に失敗したりする可能性があります。

于 2012-06-15T10:13:03.390 に答える