这是一个创建于 4464 天前的主题，其中的信息可能已经有所发展或是发生改变。
我今天，花了几个小时 pull 下来一个仓库。
Receiving objects: 85% (2044/2382), 33.58 MiB | 6 KiB/s
我当时看到 33.58 的时候还木有反应过来。。。
我还一直发推抱怨 phpfog 的 git 服务器慢。。。
我当时应该在看到 33.58 的时候就觉得不对了。。。
有哪个非大型项目的 git 仓库有那么大的。。。。
然后我打开 sourcetree 想审查一下提交记录。。。。
结果一看 git 仓库的文件列表，整个 uploads 目录里面上百个文件都在里面。。
当时我就震惊了，然后一口老血吐在屏幕上。。。
1）例如 wordpress，因为插件目录有时候是有必要用 git 管理的，而且 phpfog 的默认 wp 就是这样的。这时，过后台升级插件，下一次 push 总会变回升级前的样子。
2）因为git有历史记录的，也就是说所有文件，只要曾经存在过，就会被保存在git仓库里，那么之后git目录只会越来越大。虽然可以通过 -f 等形式处理掉，但是貌似木有容易的、能同时保留下来其余文件的历史记录的方法。
3）用git管理大量二进制文件等于拿git来当纯上传工具，这太杯具了
4）在git服务器速度不快或者限速保证性能的情况下，pull一次全部的要几个小时。。。。。
发完贴之后，我还要去给人家擦屁股。
啊啊当然了，发帖绝不是想鄙视谁，只是觉得可以当作一个事例大家共勉。
希望以后我再也不要pull到这样的仓库。
Receiving objects: 85% (2044/2382), 33.58 MiB | 6 KiB/s
我当时看到 33.58 的时候还木有反应过来。。。
我还一直发推抱怨 phpfog 的 git 服务器慢。。。
我当时应该在看到 33.58 的时候就觉得不对了。。。
有哪个非大型项目的 git 仓库有那么大的。。。。
然后我打开 sourcetree 想审查一下提交记录。。。。
结果一看 git 仓库的文件列表，整个 uploads 目录里面上百个文件都在里面。。
当时我就震惊了，然后一口老血吐在屏幕上。。。
1）例如 wordpress，因为插件目录有时候是有必要用 git 管理的，而且 phpfog 的默认 wp 就是这样的。这时，过后台升级插件，下一次 push 总会变回升级前的样子。
2）因为git有历史记录的，也就是说所有文件，只要曾经存在过，就会被保存在git仓库里，那么之后git目录只会越来越大。虽然可以通过 -f 等形式处理掉，但是貌似木有容易的、能同时保留下来其余文件的历史记录的方法。
3）用git管理大量二进制文件等于拿git来当纯上传工具，这太杯具了
4）在git服务器速度不快或者限速保证性能的情况下，pull一次全部的要几个小时。。。。。
发完贴之后，我还要去给人家擦屁股。
啊啊当然了，发帖绝不是想鄙视谁，只是觉得可以当作一个事例大家共勉。
希望以后我再也不要pull到这样的仓库。
 |
1
hzlzh 2012-09-05 01:13:12 +08:00
见到过git/svn当FTP用的不止一次两次了。习惯吧~
|
 |
4
evlos OP @hzlzh 。。。。。。。。好想哭，虽然git可以作为纯上传工具这没问题，但是我这个仓库同时还要管理代码，而且还不给我分成两次commit QAQ。而且回头如果通过网站后台删除了这个文件，我记得下次push一次如果本地木有删除这个文件的话，服务器上又出现了 - -。
P.S. 啊啊说是pull而不是clone是因为这个仓库是我init的，但是之后就交给其他人负责了，今天帮忙才pull了一次。。 |
|
5
evlos OP 终于弄（擦）完了。
今天这个仓库在phpfog一直提示500错误。 经测试，PHPfog 上如果新建了 Wordpress 应用之后，git clone 下来，再在 wp-content 下建一个 uploads，然后 push 上去就会错误。因为那里本来就存在一个独立于 git 之外的 uploads 目录。冲突了。这就是随意用 git 管理 uploads 的后果。 好想哭。。。 |
|
6
hzlzh 2012-09-05 12:01:48 +08:00
没有分成两次传才是你这次悲剧的源头所在吧，所以好习惯是多push，多小功能提交。
|
 |
7
feiandxs 2012-09-05 13:07:28 +08:00
我自己现在也架了git当某些时候dropbox的替代品用了。
恩，各种塞，每日push。。。 不过我是出于害怕本地硬盘崩盘的缘故。倒也不会经常clone或者pull。。 |
Select Language