If a force push or branch deletion occurs, the old object that the ref pointed to may cease to be referenced by any ref and thereby be eligible for garbage collection.

In the duration of the git post-receive hook of such a push, is the old object guaranteed to still be valid?

If a force push or branch deletion occurs, the old object that the ref pointed to may cease to be referenced by any ref and thereby be eligible for garbage collection.

In the duration of the git post-receive hook of such a push, is the old object guaranteed to still be valid?

• git
• githooks

• garbage collection will not kick in during a post-receive hook – LeGEC Commented yesterday
• @LeGEC I'm looking for documentation (or stable code) that says so; my testing does show that this seems to be the case, but I need this to be guaranteed – Runxi Yu Commented yesterday
• 1 To rephrase 1) A force push happens 2) this triggers a post-receive hook 3) that hook tries to reference a now dangling commit. Your question is if somewhere between 2 and 3 garbage collection can happen? You could test that. Write a post-receive hook with a long sleep and then trigger garbage collection on the remote repo and see what happens. – Schwern Commented yesterday
• After searching for gc in the Git docs. The only bit of information that slightly says when git gc is triggered is the following part from git gc docs: "When common porcelain operations that create objects are run, they will check whether the repository has grown substantially since the last maintenance, and if so run git gc automatically." Force push or branch deletion do not create objects (blobs, trees, commits, or tags), they only update or delete refs. – dani-vta Commented 23 hours ago
• Although some commits might become unreachable, and therefore eligible for gc, after a force push or a branch deletion, the documentation doesn't seem to imply that they could be responsible for it. Could it be that your hook performs some operation that would trigger an automatic gc? – dani-vta Commented 23 hours ago

2 Answers 2

I think the point made by @j6t is correct: I don't think there is a formal guarantee.

That being said: the code tries to be explicit about it.

You may look at the implementation of the server-side receive-pack action (code from v2.48.1):

int cmd_receive_pack(int argc,                      // l.2503
  ...) {

    [...]
    run_receive_hook(commands, "post-receive", 1,   // l.2610
        &push_options);
    [...]
    if (auto_gc) {                                  // l.2615
        struct child_process proc = CHILD_PROCESS_INIT;
        if (prepare_auto_maintenance(1, &proc)) {
            [...]

and note that the execution of the post-receive hook (l.2610) happens before an explicit call to the "auto_gc" action (code block starting at l.2615).

So if your post-receive hook is synchronous, this autogc action will not delete obsolete commits before running your hook.

git also has a basic locking mechanism on its database to prevent concurrent actions to do bad things, so I think other gc actions would be rejected during the execution of your hook (I haven't brought evidence of this point in this answer though).

There is no formal guarantee that the dangling object remains valid, because it is impossible to know when a post-receive hook (or any git command for that matter) has completed their operation.

The only provision that exists is that garbage collection will give objects a "short lease of life" after they become dangling. "Short" here means two weeks and is configurable. The intent is that this time span will be enough for any ongoing git command to complete and to have stopped using the dangling objects.