0

マージの競合によってファイル全体が競合するという問題がありました。これは、マージ時にローカル ファイルの改行がすべて unix スタイルの改行 (LF) になることになりました (マージ前に、開発ブランチと機能ブランチの両方がチェックアウト時に CRLF 改行を持っていました)。

走ったら

git rm --cached -r .
git add -A

git status に変更は表示されません。しかし、.gitattributesファイルを削除して別のファイルをすべて削除/追加すると、特定のファイルが別の新しい行で更新されました。たとえば、100 行のファイルの場合、100 行が削除され、100 行が追加されます。両方のブランチに対してこれを行った後、マージは問題ありませんでした。

.gitconfigautocrlf = trueが設定され、.gitattributes ファイルにはこれらの行しかありませんでした。以下の行は、マージ戦略にのみ影響すると思います。

*.csproj -text merge=union
*.sln -text merge=union

この .gitattributes が新しい行のコミット方法を変更するのはなぜですか?

また、autocrlf を true に設定すると、.gitattributes 内の何かがそれをオーバーライドしていない限り、なぜマージが LF と CRLF を比較するのかわかりません。

https://help.github.com/articles/dealing-with-line-endingsから

必要に応じて、特別な .gitattributes ファイルを構成することで、リポジトリごとに Git が行末を管理する方法を構成できます。このファイルはリポジトリにコミットされ、個々の core.autocrlf 設定をオーバーライドして、Git 設定に関係なく、すべてのユーザーに対して一貫した動作を保証します。.gitattributes ファイルの利点は、ライン構成がリポジトリに関連付けられていることです。

これにより、.gitattributes が autocrlf をオーバーライドできることは明らかですが、eol 変換を実行するように指示する設定はありません。おそらく、暗黙的に使用されるデフォルトがいくつかあります。

4

1 に答える 1

1

これは古い質問だと思いますが、関連する問題を抱えている人にとっては答えが役立つかもしれません。

gitattributes ファイルは-text、* .csprojおよび * .slnファイルを指定します。これは、これらのファイルに対して EOL 変換を行うべきではないことを意味します。

一方、構成も使用しましたautocrlf = true。この設定は、LF 行末を持つファイルを Git リポジトリに保存し、ネイティブ行末を持つファイルを作業ディレクトリに保存することを意味します。

そのため、gitattributes ファイルを追加する前に、autocrlf 設定により、* .csprojおよび * .slnファイルが LF 行末で Git リポジトリに保存されます。gitattributes ファイルを追加し、作業ディレクトリでこれらのファイルをチェックアウトした後、EOL 変換は行われず、これらのファイルは作業ディレクトリで LF 行末で終了します。

于 2015-03-03T23:15:31.993 に答える