在 wiki 页面上拥有一个单独的grbl-builds存储库以及用户友好的下载链接怎么样？

他们只字不提在回购协议中接触文件，所以拥有一个builds/文件夹应该是完全合法的。他们还抱怨大的二进制文件——AVR 图像既不大也不二进制

请不要将图像与源代码放在同一个存储库中。它
使以后重构代码成为一场噩梦。

在 2012 年 12 月 12 日星期三上午 7:04，Radu – Eosif Mihailescu <
notifications@github.com > 写道：

他们只字不提在回购协议中接触文件，所以拥有一个构建/文件夹应该是完全合法的。他们还抱怨大的二进制
文件——AVR 图像既不大也不二进制

—
直接回复此电子邮件或在 GitHub 上查看它 https://github.com/ /issues/148 #issuecomment-11286409。

@phord仅仅是因为最初的下载量可能更大吗？因为您不会以其他方式接触它们，所以您永远不必再区分或运输它们。

此外，<rant>Git 应该支持目录级语义，就像 SVN 那样</rant>（开玩笑），这样你就可以只“从这里开始”签出，而不是拉入整个树。

使用bitly和公共 Dropbox 帐户怎么样？Bitly 应该提供免费分析和 Dropbox 免费无限制访问存储。这有什么问题吗？

知道了。使用 bitly 进行分析以从 grbl-builds 存储库链接。将把链接放在 README 页面上。

@radu：二进制文件使项目变得更大更慢。这
似乎是一件小事，但它确实导致许多 git 工具
变慢或更难使用。它对合并造成严重破坏。
它会燃烧不应该点亮的cpu周期。但不，这与下载时间无关。

Phil
在 2012 年 12 月 12 日上午 10:13，“Radu – Eosif Mihailescu”<
notifications@github.com > 写道：

@phord https://github.com/phord是否只是因为最初
的下载量可能更大？因为您不会以其他方式接触它们，所以
您永远不必再区分或运输它们。

此外，Git 应该支持目录级语义，就像 SVN 那样
（开玩笑），这样你就可以只“从这里开始”签出，而不是
拉入整个树。

—
直接回复此电子邮件或在 GitHub 上查看它 https://github.com/ /issues/148 #issuecomment-11292510。