我在这里写了更多关于它们的内容,作为我的本周 git 技巧系列的一部分。
http://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
注释本身是存储在单独的 ref 文件 ( refs/notes/commits
) 中的 blob,并由它们指向的提交组织 (so git ls-tree refs/notes/commits
) 给出了一个树对象(想想:目录和内容),其中每个目录名称都是它们指向的东西to 并且每个值都是一个包含注释消息本身的 blob。
您可以在 GitHub 中查看 Gerrit 在 JGit 审阅树中使用审阅笔记(使用refs/notes/review
而不是refs/notes/commit
但本质上完全相同的原则),请访问此处:
https://github.com/eclipse/jgit/tree/refs/notes/review
由于它也是一个 ref,并且文件内容的增量与提交一起存储,因此您可以看到正在更改的各个注释,例如:
https://github.com/eclipse/jgit/commit/de70108c883afe563a48352c05cdd440c25f58cc
注意文件名显示为对象的路径;在上述情况下,de70...
是添加消息的提交,但提交的内容正在更改3a/bf...
与此提交对应的文件:
https://github.com/eclipse/jgit/commit/3abf35bc0fc7a1c130e8fec42083ffd21c342129
如果您将那里的评论链接追踪到原始 Gerrit 源:
https://git.eclipse.org/r/#/c/54632/
您会看到评论数据与 notes 元素的数据相对应。
至于它们是否干净地合并 - 因为每个注释对应于每个提交,并且每个提交一旦更改就不可变,并且注释提交是基于每个目录/文件的,您可以轻松地让不同提交的多个注释重叠而不必担心合并冲突。但是,如果两个程序/进程更新相同的提交注释,那么您可能会遇到需要以与任何其他 DVCS 合并相同的方式解决的合并问题。
一般来说,需要存储正交信息的程序应该使用自己的笔记空间,就像 Gerrit 为refs/notes/review
. 因此,如果您有refs/notes/program1
并且refs/notes/program2
您将永远不会发生碰撞。