从Github Webhooks和.git /确定分支点

Question

I'm trying to track the history of a repo on Github as it's created. Tracking a linear history is simple enough with the PushEvent , but I'd also like to track branches, merges, etc.

From playing around with it so far, it seems like a PushEvent 's before field only gives you the previous commit on the ref that was pushed, so if you create a branch called test and push to it, the previous commit is 000000 since there was no previous commit on test . The CreateEvent only tells you that a branch was created, but it doesn't seem to tell you what the branch point was.

From what I can tell, the only way to get around this is to pull the repo and crawl .git/ to reconstruct the full history DAG. Is that correct, or is there another kind of event that I should be looking into?

Also, if I'm trying to recreate the history from .git/ , logs/refs/head/{branch name} only gives you something like this:

3e0bad... 3e6422... {Author} 1458238937 -0700 merge test : Merge made by the 'recursive' strategy.

This doesn't tell you which commit was merged with 3e0bad... to create the merge commit. Is the only way to do it to go to logs/refs/head/test and look at the latest commit before the timestamp 1458238937 , or is there somewhere else that the parent commits are stored explicitly?

Thanks in advance!

Answer 1

The information really isn't available.

Consider, for instance, the following sequence of commands:

$ 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

Note that I'm not pushing b1 here.

At this point, origin (whether github or any other site) receives, from us:

• commit b100000... (this hash is made up of course; the name starting with b1 is meant to tell us that b1 was created "from" master using branch b1 );
• commit b200000... ;
• any trees and/or file blobs needed for those two commits (presumably updated trees and blobs for file file , although it's possible, however unlikely, that the required tree and file blobs are already present due to the new trees and files matching some existing trees and files); and
• a request to set refs/heads/b2 to b200000... .

The new commits have the usual metadata: commit b100000... has whatever master pointed-to as its parent, and b200000... has b100000... as its parent. Let's assume that master has not moved since the clone, and call its commit a000000... .

Presumably neither b1 nor b2 exist on the server. The server's hook therefore gets an update that creates refs/heads/b2 pointing to b200000... , ie, the "old" SHA-1 is the null hash.

If, on the server, we accept this push, and then look at the resulting commit graph, we'll see b2 pointing to b200000... , which points to b100000... , which points to a000000... , which is on an existing branch, master . We will then conclude that branch b2 was created directly from master.

But it wasn't!

If I now git push origin b1 , I will send no objects ( origin already has everything needed) and a request to set refs/heads/b1 to b100000... . This will be another branch creation in the hook, but this time b1 is being created pointing to a commit that's already on branch b2 . Where shall we now decide that b1 was created from?

Also, if I'm trying to recreate the history from [a reflog, and I encounter a merge ...]

The commit that was current before the merge occurred is always the first parent of the merge commit itself. The merged-in commit is, in the graph, identified by the 2nd (or in the case of an octopus merge, 3rd, 4th, etc) parent of the merge. As you have seen, the text in the reflog contains the argument presented to git merge , which may be a branch name, or a tag name, or indeed anything acceptable to git rev-parse (see the gitrevisions documentation ).