GitHub に小さなプロジェクトがあります。プロジェクトには Readme.txt が含まれています。リポジトリですべてが正常に機能し、改行がまだ残っていますが、ユーザーがリポジトリから .zip ファイルをダウンロードすると、改行が消えます。
例：
これは線です。
これは別の行です。
This is an indented line.この線はずっと下です。
になります：
これは線です。これは別の線です。これは意図した線です。この線ははるか下にあります。
この動作により、特にインデントが多い場合、Readme.txt がかなり読みにくくなります。
これを修正する方法はありますか？できれば、ファイルの種類を変更する以外に。
明確にするために、GitHub ページの [ZIP をダウンロード] ボタンを使用して、Git を使用せずにこれを行うことを目指しています。
nulltokenが説明したように、これは GitHub がgit archiveLinux マシン上で実行され、デフォルトで Linux の行末になるという事実が原因です。これは、リポジトリ内のファイルの行末を明示的に設定することで変更できます。これを実現するに.gitattributesは、リポジトリのルートに次の内容のファイルを作成してコミットします。
*.txt eol=crlf
そのファイルを含むすべての GitHub が作成したリビジョンの zip はCRLF、すべてのファイルで行末を持つようになり.txtます。*の代わりに を使用してすべてのファイルに展開できます*.txtが、Linux ユーザーを悲しませるので、これはお勧めしません。
内部的には、GitHubの"Download Zip"git archive機能が を活用しています。
git archiveポイントされたコミットのチェックアウトを実際に実行し、内容を tar または zip アーカイバにストリーミングします。
チェックアウト プロセス中に行末が処理される方法は、最終的にコマンドが実行されているプラットフォームに依存します。
GitHub サーバーは Linux ベースであるため、選択されたテキスト ファイルの行末は Linux ネイティブ (つまり LF) になります。
したがって、(現在) これを妨害する方法はなく、zip/tar ダウンロード内のテキスト ファイルは LF で終了します。
しかし、あなたはまだかもしれません
A possibly better option than eol=crlf which always converts LF to CRLF, is to use -text which never converts either way.
*.patch -text
(I haven't tested this yet.)