.gitattributesの変更を有効にする方法
最近gitを使い始めたプロジェクトに取り組んでいます。セットアップは最初から完璧ではなかったので、人々がクローン作成/作業を開始した後で.gitattributesをセットアップしましたが、このファイルにまだいくつかの変更を加えています。
次の設定を検討してください...
アリスとボブの両方が "repo.git"のクローンを作成し、リポジトリにはファイル/myproj/src/file.endingに\nが行末として含まれています。つまり、ファイルには\r文字が含まれていません。
また、どちらにも.gitattributesがあり、次のように設定されています。
/myproj/src/file.ending -text
これはfile.endingをテキストファイルと見なすべきではないため、行末変換は行われないことをgitに伝えます。
したがって、アリスとボブの作業ツリー内のファイルも、行末として\nを持っています。
これで、アリスは.gitattributesに次の変更を加えます。
/myproj/src/file.ending text
アリスは、彼女とボブの両方にこの変更を有効にしたいと考えています。
私が今知っている唯一の方法は非常に煩わしいです：
git rm --cached -r .
git reset --hard
私は2つのことを避けたいと思います：
- アリスは実際にテストする前に、 `.gitattributes`ファイルをコミットする必要があります（上でリセットすると変更が上書きされます）。
- ボブは更新を取得するためにインデックスと作業ツリーをワイプする必要があります。ボブは幸せではありません。
これを行う好ましい方法は何ですか？
ハードリセットする必要はありません（私があなたが何をしているかを正しく理解している場合）。
私の場合も同様です。実行中のプロジェクトに.gitattributesを追加しました。私が持っているファイルとオンラインリポジトリ内のファイルがgitattrによって支配される必要があります。
# This will force git to recheck and "reapply" gitattributes changes.
git rm --cached -r .
git add -A
コミットすると、言及した.endingファイルがすべて追加され、変更内容が失われることはありません。もちろん、ボブはそれを取得するために引っ張らなければならないでしょう。
「この変更を有効にしたい」ということは、アリスが自分とボブの両方の作業コピーをWindowsスタイルの行末に切り替えることを望んでいるということですか。では、最初の問題は、なぜアリスがボブの作業ツリーの内容に責任を負うのかということです。
ファイルが新しい属性でより適切に記述されている場合は、そうしてください。 .gitattributesファイルは、他のファイルと同じように編集、テスト、およびコミットできます。
新しい属性を有効にするために提案する手順は、次の2つの理由であまり意味がありません。
まず、なぜインデックスをワイプするのですか？ text属性は、インデックスと作業コピーの間の関係に影響を与えます。あなたの例では、それはあなたが変更する必要がある作業コピーであり、インデックスではないようです。
次に、インデックスからすべてをワイプしているのはなぜですか？属性が変更されたパスのみに対処する必要があります。
したがって、あなたの例では、アリスが新しい属性をローカルに反映したい場合、必要なもののほとんどは
rm myproj/src/file.ending
git checkout -- myproj/src/file.ending
この手順では.gitattributesファイルが上書きされないため、途中でコミットする必要はありません。
ボブがあなたの元の手順に正確に不満を感じている理由は私には明らかではないので、これが彼を幸せにするかどうかはわかりません。おそらく、彼はプルするときに更新を自動的にしたいだけです。それを期待することは不合理ではありませんが、Gitが機能するので、カードの中にあるかどうかはわかりません。
問題は、変更がどのように検出されるかです。ほとんどすべての状況で、gitがマージまたは早送り（プルの完了など）の最後に作業ツリーを更新する場合、古いコミットと新しいコミットのインデックス付きオブジェクトのハッシュを比較するだけで、適用する変更。
例外は、属性（またはフィルター定義）が変更された場合です-上記のように、それはインデックスを変更しません。しかし、これらの条件は比較的まれであり、それらのチェックはmuchほぼ常に正しいハッシュチェックよりも高価であるため、ほとんど無意味なコストですべての比較に負担をかけるのではなく、gitはそれを知っているときにそれを可能にします特定のことをしたなら、あなたは追加のステップを踏まなければなりません。
したがって、これが1回発生する場合は、チームに連絡してください。 「このパスの属性は変更されています。影響を受けるファイルの作業コピーを更新することをお勧めします。」
それが繰り返し発生する場合、私の最善のアドバイスは、これがなぜ発生し続けるのかを理解して修正することです。属性の変更を検出して対処するために、おそらくフックを使用して、ある種のスクリプト化された自動化をセットアップしようとすることができます。しかし、それは非常に複雑であり、修正するよりも多くの問題を引き起こす可能性があります。
osse on irc://chat.freenode.net/#gitは私にこのメソッドを与えました、そしてそれはかなりうまくいきます：
git rm -r :/ && git checkout HEAD -- :/
ツリーでコミットされていない変更がある場合、これは文句を言うでしょう。
しかし、もっと良い方法があるはずです。