Git Git 还可以更好!

Saito · 2012年06月06日 · 最后由 zlx_star 回复于 2012年06月20日 · 7380 次阅读

Encoding:

Encoding 是 VCS 系统该考虑还是不该考虑的?

Git 告诉我们不需要: git log man page .

At the core level, git is character encoding agnostic.

The pathnames recorded in the index and in the tree objects are treated as uninterpreted sequences of non-NUL bytes. What readdir(2) returns are what are recorded and compared with the data git keeps track of, which in turn are expected to be what lstat(2) and creat(2) accepts. There is no such thing as pathname encoding translation.

The contents of the blob objects are uninterpreted sequence of bytes. There is no encoding translation at the core level.

The commit log messages are uninterpreted sequence of non-NUL bytes.

Although we encourage that the commit log messages are encoded in UTF-8, both the core and git Porcelain are designed not to force UTF-8 on projects. If all participants of a particular project find it more convenient to use legacy encodings, git does not forbid it. However, there are a few things to keep in mind.

对比一下其他 VCS 系统,HGSVN .

简单来说:一个没有对 commit log 与 path 做 encoding 的 VCS 系统会有两方面的问题。

第一,万恶的 windows 存在各种奇葩的 encoding, 这需要不同语言之间做兼容,不然会因为编码的原因无法 clone 成功或者无法知道 commit log 具体是什么内容.( 一个 workaround 的办法是:大家都用 msysgit patch 过的 utf8 版本的 Git Client) .

第二,作为一个 Github Like 系统的开发人员会做的很辛苦。因为没人知道 push 到仓库的代码是什么编码,甚至路径与提交信息都是别种的编码。所以几乎处处都需要 detect 编码,以及转换,效率很差。因为 Git 客户端没有在最适合的时候做最应该做的处理,所以导致越外层效率越差,而且效果不好。Github

Submodule:

submodule 作为一个相对于 svn 的 co 子目录被开发出来。现阶段除了在 vim 插件领域大家应用广泛之外。在现实开发领域很少有人会使用。( 有使用经验的可以举手。分享一下经验。)

值得欣喜的是 subtree 已经被开发出来并 merge 到了 master. 这个值得期待。是否实用暂时不清楚。

HTTP Support:

Git 在 1.6 之后才开始支持 smart http transport 协议,并且在最近的一个发布版里面增强了 http 协议的功能,但是还是不够。在最近的 1.7 发布版里面 Git 默认支持了短时效的认证信息缓存功能,默认有 15 分钟。对于 Mac 版则可以将认证信息存储在 key-chain 里面 ( 貌似需要打 patch. ).

现阶段大家在 workaround 的方法一般都是:在 home 下面 新建 .netrc 文件,利用 curl 的附带认证信息的能力,完成默认的认证。否则每次提交都需要重新输入密码。( 如果觉得每次输入密码这样安全的话,可以忽略这一条。或者你本身 ssh-keygen 之前都是需要输入密码的,也可以略过。)

Future:

我最期待的是:Git 2.0 能解决 Encoding 的问题,当然这个涉及到很多打破兼容性的问题,虽然可能性非常小,但是真的值得做。

最后,欢迎补充与各种批评指正。

原文链接:http://saito.im/note/Drawbacks-of-Git/

那还是用 hg 吧 ...

git is character encoding agnostic是不是说和 Ruby1.8 类似,字符串是没有编码概念的,内部都是存储的字节序列?不知到我理解的对不对。 感觉这样无论在什么系统上面都不会产生编码问题,都没有编码啊。。。 只是在显示的时候需要去猜测。

#2 楼 @hooopo 嗯。内部存储都是 ascii-8bit 的字节序列。虽然非 utf-8 的 commit message 会有 warning 提示。但是不是说不能存储。

因为不考虑编码,所以 windows 机器上的 gbk 编码 在 linux/mac 上 clone 就会出问题。utf-8 编码的中文目录,在 windows 上 clone 会进行不下去。因为目录名的编码不对。这些都是问题。

不考虑编码,大家编码是相同的。就没有问题。大家一不同,这个就难处理了。

我在 github 上有一个 satan 项目:https://github.com/SaitoWu/satan 这个你可以自己测试一下。就知道问题了。可以 checkout 到不同 commit 测试一下,在 linux/mac 机器上。

submodule 有一个实用例子是给 assets pipeline 打包党用,把 js 库的源作为子模块放到 verden 下面,可以方便的更新版本。

Submodule 很好用啊。我经常用。。

最值得吐槽的是 git clone 的原理,如果你 clone 一个大的 git 库,比如 linux。中间如果断了,就得重新 clone。好吧,我要 clone linux ..... ,好吧我要 clone android....亚历山大啊!!

#4 楼 @Rei 多应用共享模型层代码的时候我是使用 submodule 来做的

我可不可以换个角度回答楼主的问题:

既然在 Windows 下,为什么非要用 Git ?

目前 git 的 submodule 设计得很差,在配置 vim 时用到,出过很多奇怪问题

#4 楼 @Rei 嗯,这个方式跟 vim 异曲同工啦..

#7 楼 @zw963 这个角度我着实不知道怎么理解了。

HG 死忠路过,从 05 年就开始用 HG,主要是因为 HG 一开始就用 Python 写的,跨平台性好

#10 楼 @ShiningRay 据查 HG 本身在 1.0 时代的时候也是没有处理编码问题的,在 2.0 开始着力改善这个部分。说实话,这方面做的最好的是 SVN.

#11 楼 @Saito 当时选 HG 这个 dvcs 只是因为他能在 windows 上跑,然后我正好在用 python,没了

#12 楼 @ShiningRay 这个理由真好,我准备再去 SO 上看一下别人怎么评价 HG 跟 Git 的优劣的。

What is the Difference Between Mercurial and Git?

#15 楼 @chen_bin 基本上可以说没有什么是完美的,当你越深入一件东西。你才越能发现这个东西的缺陷。

而且所有人都觉得重新开发一个会更好,但是实际上你已经陷进去了。

所以 Git 可以更好的意思不是说 我会去转去用 hg. 也没有争论哪个会更好。只是辩证的看缺陷这个问题而已。

Zed A. Shaw - The Web Will Die When OOP Dies 昨天在 Zed A. Shaw 这个 programming mother-f_cker 的演讲上浪费了 30 分钟。跟大家分享~

不知道怎么说,我觉得 hg 的分支功能有种形同虚设的感觉。git 可以在各个分支之间切换,就像平行空间一样,而 hg 必须提交的时候合并才能到达另一个分支。

在网上看到一种说法“hg 只是分布式的 svn”,我感觉有点道理。

#17 楼 @tonyseek hg bookmark = git branch

实际上,是 git 缺少 hg 的 branch 功能。

我现在依旧认为,对于成熟的开源项目来说,hg 的 branch 还是需要的。

我认为 1.X 2.X 这样的应该弄成 hg branch (一个比较明显的好处是能知道某个 commit 是从哪个版本 port 过来的,不需要人力去维护) feature branch 用 hg bookmark 1.1 1.2 2.1 2.2 这样的 release 用 hg tag

另外,tag 应该是全局的,写了之后就不可改的。

#16 楼 @Saito git 真的比 hg 好么?我毫不怀疑,如果搞个 feature by feature 的列表,git 会输给 hg 的。

hg 的优势,支持 (hg 风格的) branch,可以写 extension。比如,利用 keyring 里的密码,就一个 extension 的事。

http://mercurial.selenic.com/wiki/KeyringExtension

git 要实现 gerrit 的功能,用官方实现容易做么 (必须只能用发行版自带的,不准自己 patch 编译)?很不容易吧。加这么点功能都很麻烦,到底有啥好的。

目前我不在 windows 上使用 git,所以我不再关注 Encoding 问题啦, 但是,我记得,曾经我在 windows 上使用 git 的时候,那就是噩梦。

#20 楼 @ery @Saito 那 编码问题 怎么办呢?

git 如果要在多个平台下同步的话,最好保持编码为一致,最简单的办法就是所有平台都采用 UTF-8 了,这样就会省很多麻烦,另外,git 官方 for win 客户端已经支持 UTF-8 了,推荐使用。。。

在 win 上用 git,我宁可开个虚拟机。

#8 楼 @HungYuHei 目前为止没遇到问题。

win 下用虚拟机 linux git 的 好像还没碰到编码这样的问题,

之前一直使用 svn,刚刚转到 git。个人感觉在网络一直良好的情况下,svn 还是很方便的

需要 登录 后方可回复, 如果你还没有账号请 注册新账号