問題タブ [gitattributes]

git-svn を使用して、大規模な SVN リポジトリ (〜 28k コミット) を Git に変換しています。プロセスが完了したとき (~ 1 1/2 週間)、いくつかの .ps1 ファイルが差分でバイナリとして扱われているのに遭遇しました。ファイルをテキストとして扱うように git に指示する .gitignore ファイルをマスターに (もちろん変換後) コミットしました。

注: -text は、行末をそのまま扱うように指示するだけです (データベースに Unix の行末とともに保存しません)。

ただし、もちろん、変換後にのみ .gitattributes を追加できました。

.gitattributes は、以前のコミット/差分の Git 拡張機能ではうまく機能しませんが、それは今は議論したくない別の問題かもしれません。主な問題は、git にバイナリーとして保管されているファイルです。

.git/INFO の下に gitattributes を保存できることをどこかで読みました。変換プロセスの前にこれを行うこともできますが、変換には 1 週間以上かかるため、もう一度試していません。最初のストライクで正しく処理したいと考えています。

したがって、基本的に私の質問は次のとおりです。変換されたリポジトリを念頭に置いて、既存の git リポジトリ内の既存のバイナリ ファイルをテキスト ファイルに変換できますか?

そうでない場合: 変換手順全体で gitattributes を使用して、テキスト/バイナリとして扱われるファイルを git-svn にどのように伝えますか?

編集: 問題は変換 (意図的にファイルをバイナリとして扱う git) ではなく、「git diff」または Git 拡張機能によってファイルがバイナリとして扱われることでした。(回答を参照) 差分ツール (BeyondCompare など) を使用する場合でも、これらのファイルを操作できます。その場合、歴史の中で少し面倒です。ファイルがそのまま移行されたため、変換は問題なく機能しました。(つまりUTF-16)

Git 属性を使用してファイルごとにフィルターを設定し、作業ディレクトリのコンテンツをリポジトリ コンテンツの変換バージョンにすることができます。これを使用して、 Archlinux の新しい AUR バージョン 4.SRCINFOで処理する必要があるファイルをクリーンアップできるかどうか疑問に思っていました。

基本的に、 と呼ばれる 2 つのファイルがPKGBUILDあり.SRCINFO、両方ともリポジトリに保存する必要があります。私の場合、 は で呼び出されるプログラムを実行することによって生成されると安全に想定でき.SRCINFOます。両方をリポジトリに表示したいのですが、ローカル ツリーにのみ表示します。mksrcinfoPKGBUILDPKGBUILD

フィルタ ペアを設定するにはどうすればよいですか?

• 汚れは除去する.SRCINFOか、そもそもそれを作成しません。

• .SRCINFO実行によって生成されたクリーンな追加mksrcinfo PKGBUILD？

すべての Vim 設定を保存するリポジトリがあります。サブモジュールを使用して、Pathogen でプラグインを取り込みます (他のプラグイン マネージャーも調べましたが、今のところ興味はありません)。

MSYSGit がコミット メッセージのために Vim を開いたときに行末を処理する方法のため、リポジトリに Unix 行末 (eol=lf) を格納する必要があります。

メインリポジトリに.gitattributesファイルをコンテンツとともに追加しようとしました:

git rm --cached -r .とを使用してメイン リポジトリを更新した後、メイン リポジトリgit reset --hardの行末は LF になりました。ただし、サブモジュール内で同じコマンドを実行しても機能しませんでした。

サブモジュールがLF行末でチェックアウトされるようにgitリポジトリを構成するにはどうすればよいですか?

veracrypt は、私の git 設定ファイルへの変更が認識されるのを妨げている可能性があるメモリ内のファイル キャッシュのようなものを実行しますか?

長いバージョン: Windows と共有されている veracrypt パーティションにレポがあります。レポで EOL を強制しようとしているときに、多かれ少なかれ恣意的に EOL を設定しているファイルが表示されます。.gitattributes ファイルに些細な変更を加えると、この変更をブランチにマージすると、突然新しいブランチが EOL のみの変更を含むファイルでいっぱいになります。

私は主に SmartGit または cmd-line (git v 1.8.3.1) を使用して Linux で作業しています。autocrlf と safecrlf を削除するか、グローバル設定ファイルとレポ設定ファイルの両方で false に設定して、混乱を招く場合に備えて試しました。.gitattributes ファイルまたは設定を削除しようとしました

変換をまったく防止します。

何十回もリセットし、ローカルリポジトリを削除して再クローンしました。しかし、これらの変更されたファイルを取り除くことはできません

以下は私の.gitattributesです

私の主な問題は、一部の (すべてではない) .so シンボリックリンクが特定のブランチで変更されて表示されることです。変換されたように世界中を探しています。これは私の最新のブランチで一貫して発生しますが、以前のブランチでは発生しません。現在の混乱の中で、私の最後のマージで *.cpp タグが追加されました。これにより、*.py ファイルの一部 (すべてではない) がすぐに Windows の行末に変換されました。

この種の信頼性の低さを経験した人はいますか? .gitattributes ファイルはこのバージョンの git でサポートされていますか? veracrypt または NTFS パーティションは、どうにかして私を混乱させますか?

私は 1 週間、些細な作業に取り組んできましたが、git が EOL 戦略をどのように決定しているかを理解することはできません。

SVN リポジトリを Git にインポートしていますが、set を持つファイルがたくさんありますsvn:eol-style。SubGitはこれらのプロパティを読み取り、すべて.gitattributesのファイルの行を生成します。

すべてのタイプのファイルにシングルライナーを使用するように指示する方法はありますか (つまり*.java text、*.java text eol=lfそれを義務付けるスタイル ガイド ルールがあるため)。

info/attributesインポートの直前に をリポジトリに追加しようとしましたが、生成された に変更はありません.gitattributes。

それを行う方法はありますか？

一部のプロジェクト ファイルの上部に小さなヘッダーがあり、変更を加えるたびに現在の年に更新されるようにしたいと考えています。エラーをスローする git のクリーン フィルターに問題があります。

testClass.csまず、 master ブランチで次のファイルを呼び出します。

次に、ファイルに小さな変更を加えます。

次にgit add testClass.cs、次のコミットのために変更をステージングします。sedこれにより、ファイルをインプレースで編集してヘッダーの年を 2015 に更新しようとするgit clean フィルターが実行されます (つまり、2011-2014 は 2011-2015 に変更する必要があります)。フィルター設定を含む構成は次のとおりです。

私が抱えている問題は、「デバイスまたはリソースがビジー」エラーのために追加/更新が失敗することです。sed が作成する一時ファイルと関係があるようです。sed コマンドは、コマンド ラインでテストすると正常に動作しますが、フィルターとして使用すると失敗します。

git bash バージョン 2.5.3 (MINGW64) を使用しています。

この投稿に基づく: `.gitattributes` ファイルの `text=auto` の目的は何ですか? .gitattributes ファイルに次のものがある場合、行末はテキスト ファイルのLFに 変換されます。

これをローカルリポジトリでテストしました：

しかし、そこにはCRLFに変換されると書かれています。上記の投稿では、このテストでは当てはまらないLFに変換されると書かれています。

したがって、次のようです。

OS に基づいて行末タイプに変換されます (Windows では CRLF、Linux では LF)。しかし、それはここで説明されていることではありません:

https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

以下のコメント/回答に基づいて、これが原因で警告が発生したようです:

.gitattributes ファイルで:

実際には、チェックアウトを実行すると(次にリポジトリから作業ディレクトリにファイルをチェックアウトするとき)、現在LFで終わるテキスト ファイルがCRLFを持つように変換されることを意味します。

警告は、チェックイン行にLFエンディングがあることに対処していません。これは、ドキュメントに次のように記載されています。

https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

文字列値 "auto" に設定 テキストが "auto" に設定されている場合、パスは自動行末正規化用にマークされます。Git がコンテンツがテキストであると判断した場合、その行末はチェックイン時に LF に正規化されます。