14

TFS で開始され、その後 Git に移行されたプロジェクトがあります。残念ながら、それを Git に移動した人は、git-tfs を使用する代わりに現在のファイルをチェックインしただけです。git-tfs を使用して TFS からプルしたコミットの上に、Git で彼の新しいコミットをリベースしようとしています。

これを行うには、git-tfs コミットの上に彼のコミットをリベースするだけです。(リモートの Git ブランチが台無しになることは承知していますが、私たちは小さなチームなので問題ありません。代わりにチェリー ピッキングも試しましたが、同じ問題に遭遇しました。)

私が直面している問題は、次のような一連の競合です。

<<<<<<< HEAD
namespace OurNiftyProject
{
    public enum CardType
    { 
        Visa = 0,
        MasterCard = 1
    }
}
||||||| merged common ancestors
=======
namespace OurNiftyProject
{
    public enum CardType
    { 
        Visa = 0,
        MasterCard = 1
    }
}
>>>>>>> Add a bunch of stuff.

これは、これらのファイルを追加した TFS 側からのコミットと、それらを追加した Git 側のコミットとの間の競合のようです (Git リポジトリが空で始まったため)。

おそらく、このコミットをスキップするのが論理的ですが、その中には新しいファイルがいくつかあります (数百のうちの 10 など)。もちろん、それらは競合を引き起こしません。

2 つのファイルが同一であることを Git が判断できないのはなぜですか? リベースするときに使用しても--ignore-whitespace、Git には、このような同一のファイルが多数表示されます。これを解決する方法に途方に暮れています。

4

4 に答える 4

11

ebneterがコメントしているように、それは行末の違いに関するものでなければなりません。
git mergeが(空白の違いとは対照的に)これらの違いを無視するのがいかにうまくいかなかったかについては、すでにかなり前に詳しく説明しました。
git-mergeが行末の違いを無視することは可能ですか?

そのため、異種環境のリポジトリには一貫したeol変換ポリシーが必要です。「コードを使用したgit構成の配布
」を参照してください。

于 2012-03-30T22:44:48.967 に答える
6

私も同じようなことをしていて、「-Xignore-space-at-eol」を見つけました。マージとリベースの両方で使用できます。正しいことをしているように見えますが、私にとっては死が遅くなります。

于 2012-04-14T19:22:36.353 に答える
2

行末の違いによる目に見えない変更を除外できる場合は、ファイルのモードが異なるかどうか (たとえば、実行可能ビットが設定されているかどうか)を確認することをお勧めします。ファイル モードが変更されると、Git は完全なファイルを diff に表示します。

于 2015-02-20T13:52:47.917 に答える