Início / coding / Perguntas / 79450095
Accepted
Runxi Yu
Asked: 2025-02-19 11:12:13 +0800 CST

É garantido que IDs de objetos antigos sejam válidos durante um hook post-receive?

  • 772

Se ocorrer um push forçado ou exclusão de ramificação, o objeto antigo apontado pela referência poderá deixar de ser referenciado por qualquer referência e, portanto, ser elegível para coleta de lixo.

Durante a duração do gancho git post-receive de tal push, é garantido que o objeto antigo ainda seja válido?

git

2 respostas

  1. Acho que o ponto levantado por @j6t está correto: não acho que haja uma garantia formal .

    Dito isto: o código tenta ser explícito sobre isso.

    Você pode observar a implementação da receive-packação do lado do servidor (código da 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)) {
            [...]

    e observe que a execução do post-receivehook ( l.2610 ) acontece antes de uma chamada explícita para a ação "auto_gc" (bloco de código começando em l.2615 ).

    Portanto, se seu post-receivehook for síncrono, essa ação autogc não excluirá commits obsoletos antes de executar seu hook.

    gittambém tem um mecanismo básico de bloqueio em seu banco de dados para evitar que ações simultâneas façam coisas ruins, então acho que outras ações do gc seriam rejeitadas durante a execução do seu hook (embora eu não tenha trazido evidências desse ponto nesta resposta).

    • 5
  2. Best Answer

    Não há garantia formal de que o objeto pendente permaneça válido, porque é impossível saber quando um gancho pós-recebimento (ou qualquer gitcomando) concluiu sua operação.

    A única provisão que existe é que a coleta de lixo dará aos objetos uma "curta vida útil" depois que eles ficarem pendurados. "Curto" aqui significa duas semanas e é configurável. A intenção é que esse intervalo de tempo seja suficiente para que qualquer gitcomando em andamento seja concluído e tenha parado de usar os objetos pendurados.

    • 4

relate perguntas