Qual é a dívida?
Um relatório de atribuição de origem (90 dias, repo RocketBus/maestro-service) reportou 156 commits HUMAN, dos quais 88 (56%) seriam merge commits. A investigação mostrou:
git log --merges --since="90 days ago" no mesmo repo/janela retorna 60 merges reais (2+ pais), não 88 — a contagem do relatório não reconcilia com a realidade do git.- Os merges reais existentes são de dois subtipos: via botão "Merge pull request" do GitHub (server-side, nunca invoca hook local) e
git merge local empurrado direto pelo desenvolvedor (client-side, invoca o hook local, que intencionalmente pula source=merge).
- Pelo pipeline atual (
iris/ingestion/git_reader.py::read_commits, include_merges=False por padrão — iris/cli.py:486 e iris/org_runner.py:79 não passam override), ambos os subtipos já deveriam estar excluídos da análise antes mesmo de chegar no origin_classifier.
Ou seja: se o relatório de 156 commits realmente contou 88 merges como HUMAN, ele não passou pelo caminho padrão atual do CLI/org_runner — é sinal de versão desatualizada da ferramenta, script ad-hoc, flag include_merges=True explícita, ou uma definição de "merge" diferente da usada pelo engine (ex.: match textual em vez de contagem de pais via %P).
Por que é dívida?
Sem reconciliar isso, qualquer conclusão tirada do relatório (ex.: "56% dos commits humanos são merges, logo o gap de atribuição real é menor do que parece") fica sobre uma base numérica não verificada — e pode levar a decisões de produto erradas (como propor que o engine passe a herdar origem de commits pai, uma mudança cara, para resolver um problema que talvez já não exista no pipeline atual).
Como chegou aqui?
Surgiu ao revisar uma análise externa que propunha o engine tratar merge commits como herdando a origem do(s) pai(s) (similar ao tratamento hoje dado a bots). Ao investigar a lógica atual (origin_classifier.py, git_reader.py), ficou claro que merges já são filtrados por padrão — o que não bate com os números do relatório que motivou a proposta.
Plano de migração
Deadline / gatilho pra pagar
Antes da próxima análise de engajamento que cite métricas de commit_origin_distribution ou proponha mudança de comportamento do engine baseada nelas
Qual é a dívida?
Um relatório de atribuição de origem (90 dias, repo RocketBus/maestro-service) reportou 156 commits
HUMAN, dos quais 88 (56%) seriam merge commits. A investigação mostrou:git log --merges --since="90 days ago"no mesmo repo/janela retorna 60 merges reais (2+ pais), não 88 — a contagem do relatório não reconcilia com a realidade do git.git mergelocal empurrado direto pelo desenvolvedor (client-side, invoca o hook local, que intencionalmente pulasource=merge).iris/ingestion/git_reader.py::read_commits,include_merges=Falsepor padrão —iris/cli.py:486eiris/org_runner.py:79não passam override), ambos os subtipos já deveriam estar excluídos da análise antes mesmo de chegar noorigin_classifier.Ou seja: se o relatório de 156 commits realmente contou 88 merges como
HUMAN, ele não passou pelo caminho padrão atual do CLI/org_runner — é sinal de versão desatualizada da ferramenta, script ad-hoc, flaginclude_merges=Trueexplícita, ou uma definição de "merge" diferente da usada pelo engine (ex.: match textual em vez de contagem de pais via%P).Por que é dívida?
Sem reconciliar isso, qualquer conclusão tirada do relatório (ex.: "56% dos commits humanos são merges, logo o gap de atribuição real é menor do que parece") fica sobre uma base numérica não verificada — e pode levar a decisões de produto erradas (como propor que o engine passe a herdar origem de commits pai, uma mudança cara, para resolver um problema que talvez já não exista no pipeline atual).
Como chegou aqui?
Surgiu ao revisar uma análise externa que propunha o engine tratar merge commits como herdando a origem do(s) pai(s) (similar ao tratamento hoje dado a bots). Ao investigar a lógica atual (
origin_classifier.py,git_reader.py), ficou claro que merges já são filtrados por padrão — o que não bate com os números do relatório que motivou a proposta.Plano de migração
git log --mergesda mesma janela, para identificar a origem exata da divergênciainclude_merges=True, script ad-hoc, versão antiga): documentar/padronizar para que toda análise de engajamento futura passe poriris/cli.pyouiris/org_runner.pyread_commits/_parse_log_outputDeadline / gatilho pra pagar
Antes da próxima análise de engajamento que cite métricas de
commit_origin_distributionou proponha mudança de comportamento do engine baseada nelas