10

我在 GitHub 上有一个小项目。该项目包括一个 Readme.txt。存储库中一切正常，换行符仍然存在，但是当用户从存储库下载 .zip 文件时，换行符消失了。

例子：

这是一条线。
这是另一条线。
This is an indented line.

这条线远低于。

变成：

这是一条线，这是另一条线。这是一条预定线。这条线远低于此线。

这种行为使 Readme.txt 很难阅读，尤其是在它有很多缩进的情况下。

有没有办法来解决这个问题？最好不要更改文件类型。

为了澄清起见，我的目标是在没有 Git 的情况下使用 GitHub 页面中的“下载 ZIP”按钮来执行此操作。

4

4 回答 4

11

正如nulltoken 所解释的，这是由于 GitHubgit archive在默认为 linux 行结尾的 linux 机器上运行造成的。您可以通过显式设置存储库中文件的行尾来更改此设置。为此，.gitattributes请在 repo 的根目录中创建一个包含以下内容的文件并提交它。

*.txt eol=crlf

所有 GitHub 创建的包含该文件的修订版 zip 现在CRLF在所有文件中都有行结尾.txt。*您可以使用而不是将其扩展到所有文件*.txt，但我建议不要这样做，因为它会让 linux 用户感到难过。

于 2013-06-28T18:20:43.260 回答
3

Internally, the "Download Zip" feature from GitHub leverages git archive.

git archive actually performs a checkout of the pointed at commit, streaming the content to the tar or zip archiver.

The way the line endings are being dealt with, during the checkout process, eventually depends on the platform the command is being run on.

As GitHub servers are Linux based, the selected line ending for text files will be the Linux native one (i.e. LF).

So there's (currently) no way to interfere with this and text files inside your zip/tar downloads will be LF terminated.

However you may still

  • Use a tool like Unix2Dos to batch convert your text files
  • Send a mail to support@github.com and request for a change to their UI so that one could potentially select the expected line endings
于 2013-06-27T18:54:33.433 回答
0

如果下载 zip 不适合您，则使用标准 git 方法git archive

git archive --format zip HEAD ..\repo.zip

这会在文件的工作树中创建最新跟踪、提交文件的压缩版本repo.zip。您必须在本地存储库中执行它。

于 2013-06-27T16:43:08.587 回答
0

一个可能比eol=crlf始终将 LF 转换为 CRLF 更好的选择是使用-text从不转换任何一种方式的方法。

*.patch -text

（我还没有测试过这个。）

于 2016-01-11T11:05:45.867 回答