Question

我正在尝试跟踪Github上创建的回购历史。使用PushEvent跟踪线性历史很简单，但我也想跟踪分支，合并等。

从目前为止开始使用它，似乎PushEvent的{{1}}字段只会在推送的before上提供之前的提交，因此如果您创建了分支称为ref并推送到它，之前的提交是test，因为000000上没有先前的提交。 test仅告诉您已创建分支，但它似乎不会告诉您分支点是什么。

据我所知，解决此问题的唯一方法是拉回存档并抓取CreateEvent以重建完整历史DAG。这是正确的，还是我应该研究另一种事件？

此外，如果我尝试从.git/重新创建历史记录，.git/只能为您提供以下内容：

logs/refs/head/{branch name} 3e0bad... 3e6422... {Author}合并1458238937 -0700：由“递归”策略合并。

这不会告诉您哪个提交与test合并以创建合并提交。唯一的方法是转到3e0bad...并查看时间戳logs/refs/head/test之前的最新提交，还是在其他地方明确存储父提交？

提前致谢！

Answer 1

这些信息真的不可用。

例如，考虑以下命令序列：

$ git clone <url> repo
$ cd repo
$ git checkout -b b1 master
Switched to a new branch 'b1'
$ echo stuff >> file; git add file; git commit -m add-stuff
[b1 b100000] add-stuff
...
$ git checkout -b b2
Switched to a new branch 'b2'
$ echo more stuff >> file; git add file; git commit -m more-stuff
[b2 b200000] more stuff
...
$ git push origin b2

请注意，我不是在这里推b1。

此时，origin（无论是github还是其他任何网站）都收到了我们的信息：

提交b100000...（此哈希当然是由; b1开头的名称是为了告诉我们 b1是从“创建的”使用分支b1）;
提交b200000...;
这两个提交所需的任何树和/或文件blob（可能是文件file的更新树和blob），尽管可能（但不太可能）由于新的而已经存在所需的树和文件blob树和文件匹配一些现有的树和文件）;和
将refs/heads/b2设置为b200000...的请求。

新提交具有通常的元数据：提交b100000...具有指向其父级的master，而b200000...具有b100000...作为其父级。我们假设master自克隆以来没有移动，并调用其提交a000000...。

服务器上可能不存在b1和b2。因此，服务器的钩子获得一个更新，创建指向refs/heads/b2的{{1}}，即“旧”SHA-1是空哈希。

如果在服务器上我们接受此推送，然后查看生成的提交图，我们会看到b200000...指向b2，其指向b200000...，指向现有分支b100000...上的a000000...。然后我们将得出结论，分支master是直接从master创建的。

但事实并非如此！

如果我现在b2，我将不发送任何对象（git push origin b1已经包含所有内容）以及将origin设置为refs/heads/b1的请求。这将是钩子中的另一个分支创建，但是这次创建b100000...指向已经在分支b1上的提交。我们现在应该在哪里决定b2是从哪个创建的？

另外，如果我正在尝试从[reflog中重新创建历史记录，我遇到合并...]

合并发生前的当前提交始终是合并提交本身的第一个父提交。合并后的提交在图中由合并的第二个（或章鱼合并的情况，第三个，第四个等）标识。如您所见，reflog中的文本包含提交给b1的参数，可能是分支名称，或标记名称，或者git merge可接受的任何内容（见the gitrevisions documentation）。

确定Github Webhooks＆amp; git的/

1 个答案: