git 没有在 ref 目录中包含所有分支文件并且没有在分支引用文件中维护提交 ID。为什么?
git is not having all branch files in ref dir AND not maintaining commit id in branch reference file. Why?
据我了解,GIT 使用名称与分支名称相同的纯文本文件跟踪分支。这些文件存储在 .git\refs\remotes\origin
中,用于远程跟踪远程分支,对于本地分支,这些文件存储在 .git\refs\heads
中
下面是 git 分支的输出:
$ git branch -a
joincolumn_issue
* master
remotes/origin/HEAD -> origin/master
remotes/origin/joincolumn_issue
remotes/origin/mappedBy
remotes/origin/master
remotes/origin/todelete
第一部分problem/questions:
正如您所看到的,有几个远程分支 git 知道......但是在查看 .git 目录时我没有看到所有这些分支 -
Samsh@Sambox MINGW64 /d/graphql-hibernate/.git/refs/remotes/origin (GIT_DIR!)
$ ls
HEAD joincolumn_issue
为什么其他分支的文件不存在。行。 joincolumn_issue
以外的分支从未从远程结帐。所以如果是这个原因。好吧,如果确实如此,那么 git 如何以及从哪里获取其他分支详细信息(因为它在 git branch -a
中列出了它们,这绝对不是轮询此查询的回购)
problem/question的第二部分:
查看参考目录中文件的内容-
Samsh@Sambox MINGW64 /d/graphql-hibernate/.git/refs/remotes/origin (GIT_DIR!)
$ cat joincolumn_issue
1950d716308e5063f1b8f28c2423166781335333
这是指向提交 ID 的预期结果。美好的。但问题在于以下输出。
$ cat HEAD
ref: refs/remotes/origin/master
HEAD指的是master,.git
目录下没有这个文件。所以现在你明白我的问题了,我看不出 git 如何在没有 knowing/tracking 相关提交 ID 的情况下找出 master 的提示。
GIT keeps track of branches using plain text files with name same as the branch name.
有时,是的。有时没有。你不应该关心。您为什么要检查 .git/refs/heads/
个文件?1
Git 在某处有一个数据库,2,名称到哈希 ID 的映射。您可以使用 git rev-parse
程序从名称中提取哈希 ID:3
git rev-parse refs/heads/master
为您提供 refs/heads/master
的哈希 ID,即分支名称 master
。您可以使用 git for-each-ref
遍历部分或所有引用(请参阅其文档)。
通常,您设置 名称以使用更高级别的接口来散列 ID,例如 git branch
或 git tag
;但是你可以直接使用 git update-ref
:
写数据库
git update-ref [flags] refs/heads/master <new-hash> [<old-hash>]
表示存储新的散列;如果我提供旧哈希,请确保名称映射到现有哈希 ID,然后再进行更改。
1也许是在调试、学习,或者只是单纯的固执。 :-)
2在内部,在 C 代码中,Git 具有实现引用存储和加载的 "back ends" 的概念。当前的 "database" 真的很糟糕,由平面文件 .git/packed-refs
或取自 .git/refs/<path>
的文件组成。平面文件 "database" 工作正常——它分别存储名称 master
和 MASTER
,例如,所以这两个分支是不同的,正如 Git 预期的那样——但是本地文件系统文件树 "database" 在某些无法创建同时命名为 master
和 MASTER
的系统上严重失败。很明显,像 GitHub 这样的大型服务器提供商可以使用 real 数据库:一些存储库有数千个标签,处理平面文件和文件树是,应该我们说,"not good".
3Rev-parse 比 只是 在数据库中查找一个名字做的更多,但它确实做到了,所以为什么不用它?
据我了解,GIT 使用名称与分支名称相同的纯文本文件跟踪分支。这些文件存储在 .git\refs\remotes\origin
中,用于远程跟踪远程分支,对于本地分支,这些文件存储在 .git\refs\heads
下面是 git 分支的输出:
$ git branch -a
joincolumn_issue
* master
remotes/origin/HEAD -> origin/master
remotes/origin/joincolumn_issue
remotes/origin/mappedBy
remotes/origin/master
remotes/origin/todelete
第一部分problem/questions:
正如您所看到的,有几个远程分支 git 知道......但是在查看 .git 目录时我没有看到所有这些分支 -
Samsh@Sambox MINGW64 /d/graphql-hibernate/.git/refs/remotes/origin (GIT_DIR!)
$ ls
HEAD joincolumn_issue
为什么其他分支的文件不存在。行。 joincolumn_issue
以外的分支从未从远程结帐。所以如果是这个原因。好吧,如果确实如此,那么 git 如何以及从哪里获取其他分支详细信息(因为它在 git branch -a
中列出了它们,这绝对不是轮询此查询的回购)
problem/question的第二部分: 查看参考目录中文件的内容-
Samsh@Sambox MINGW64 /d/graphql-hibernate/.git/refs/remotes/origin (GIT_DIR!)
$ cat joincolumn_issue
1950d716308e5063f1b8f28c2423166781335333
这是指向提交 ID 的预期结果。美好的。但问题在于以下输出。
$ cat HEAD
ref: refs/remotes/origin/master
HEAD指的是master,.git
目录下没有这个文件。所以现在你明白我的问题了,我看不出 git 如何在没有 knowing/tracking 相关提交 ID 的情况下找出 master 的提示。
GIT keeps track of branches using plain text files with name same as the branch name.
有时,是的。有时没有。你不应该关心。您为什么要检查 .git/refs/heads/
个文件?1
Git 在某处有一个数据库,2,名称到哈希 ID 的映射。您可以使用 git rev-parse
程序从名称中提取哈希 ID:3
git rev-parse refs/heads/master
为您提供 refs/heads/master
的哈希 ID,即分支名称 master
。您可以使用 git for-each-ref
遍历部分或所有引用(请参阅其文档)。
通常,您设置 名称以使用更高级别的接口来散列 ID,例如 git branch
或 git tag
;但是你可以直接使用 git update-ref
:
git update-ref [flags] refs/heads/master <new-hash> [<old-hash>]
表示存储新的散列;如果我提供旧哈希,请确保名称映射到现有哈希 ID,然后再进行更改。
1也许是在调试、学习,或者只是单纯的固执。 :-)
2在内部,在 C 代码中,Git 具有实现引用存储和加载的 "back ends" 的概念。当前的 "database" 真的很糟糕,由平面文件 .git/packed-refs
或取自 .git/refs/<path>
的文件组成。平面文件 "database" 工作正常——它分别存储名称 master
和 MASTER
,例如,所以这两个分支是不同的,正如 Git 预期的那样——但是本地文件系统文件树 "database" 在某些无法创建同时命名为 master
和 MASTER
的系统上严重失败。很明显,像 GitHub 这样的大型服务器提供商可以使用 real 数据库:一些存储库有数千个标签,处理平面文件和文件树是,应该我们说,"not good".
3Rev-parse 比 只是 在数据库中查找一个名字做的更多,但它确实做到了,所以为什么不用它?