Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[rush] Managed Git LFS hooks conflict with reused Azure Pipelines workspaces

Aberta
  • Algo errado?
#6,120 0 comentários 1 reação 2 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@iclanton já está trabalhando nisso.

Desde 7/10/2026.

  • #6121 de @copilot-swe-agent — aberto

Avaliação

Esta issue ainda não foi avaliada.

Descrição

Summary

Rush's managed Git-hook installation has two incompatible failure modes when a repository also uses Git LFS:

  1. If the repository does not declare the Git LFS hook names under common/git-hooks, rush install / rush update empties .git/hooks and removes Git LFS's canonical hooks. A later git push can push LFS pointer commits without uploading the corresponding LFS objects.
  2. If the repository does declare an LFS hook name so Rush adds its built-in LFS delegation, Rush leaves a noncanonical wrapper in .git/hooks. Azure Pipelines checkout runs git lfs install --local; on a reused self-hosted agent, Git LFS rejects the existing Rush wrapper and the checkout fails before repository code can run.

This is not a recent regression. I verified the same installation logic in locally available Rush versions 5.172 through 5.180.

Related history

  • #3816 and #4132 introduced the current delegate-hook approach and its Git LFS chaining.
  • A comment on #1042 describes intentionally ignoring git lfs install errors after Rush owns pre-push. That works in a setup script, but Azure Pipelines treats the same error as a fatal checkout failure.
  • #4247 fixed error propagation from a managed pre-push hook, but does not cover hook installation interoperability.

I did not find an existing issue for the combination of hook-folder clearing, missing LFS uploads, and Azure's repeated git lfs install --local.

Reproduction A: Rush removes Git LFS's upload hook

  1. Create a Rush repository with at least one managed hook, for example:

    common/git-hooks/pre-commit

  2. Configure Git LFS:

    git lfs install --local

    .git/hooks/pre-push is now Git LFS's canonical hook.

  3. Run:

    rush update

  4. Inspect .git/hooks.

Actual result

Rush calls ensureEmptyFolder(hookDestination) and recreates only hook names represented under common/git-hooks. The canonical pre-push, post-checkout, post-commit, and post-merge hooks are removed.

A later normal git push does not invoke git lfs pre-push, so new LFS objects are not uploaded.

Expected result

Installing Rush-managed hooks should not silently remove hooks owned by another tool, especially Git LFS's upload hook.

Reproduction B: Rush's LFS wrapper breaks Azure checkout

  1. Add a placeholder such as:

    common/git-hooks/pre-push

    Rush recognizes the name and generates a wrapper that delegates to the repository hook and then invokes:

    git lfs pre-push "$@"

  2. Use an Azure Pipelines self-hosted agent with checkout configured for LFS.

  3. Run a build job that executes rush install or rush update.

  4. Reuse the same agent workspace for a later job or pipeline checkout.

Azure's checkout task runs:

git lfs install --local
Actual result

Git LFS rejects Rush's noncanonical wrapper:

Hook already exists: pre-push

    #!/usr/bin/env bash
    set -e
    SCRIPT_DIR="..."
    SCRIPT_IMPLEMENTATION_PATH=".../common/git-hooks/pre-push"
    ...
    git lfs pre-push "$@"

To resolve this, either:
  1: run `git lfs update --manual` for instructions on how to merge hooks.
  2: run `git lfs update --force` to overwrite your hook.

##[error]Git-lfs installation failed with exit code: 2

The checkout fails before any repository script can repair the hook.

This was observed with Azure Pipelines agent checkout using Git LFS 3.4.1 on Linux. The repository's developer machine used Git LFS 3.7.1 and reproduced the same git lfs install --local conflict.

Expected result

A hook arrangement produced by Rush's documented installation flow should remain compatible with common checkout tooling that initializes Git LFS, or Rush should explicitly document and validate the incompatibility.

Why this is difficult to work around

  • Omitting the placeholder avoids Azure's conflict but lets Rush remove LFS's upload hook.
  • Adding the placeholder preserves LFS behavior during git push but leaves a wrapper that git lfs install --local rejects.
  • git lfs install --local --force after every Rush install restores canonical hooks and works when the repository has no custom implementation for those hook names, but it would overwrite legitimate custom Rush-managed hooks.
  • A stale wrapper on a reused self-hosted agent can break unrelated branches before they have checked out a corrective commit.

Possible direction

The most general fix may be for Rush to stop emptying the complete hooks directory:

  • Track which hooks were generated by Rush.
  • Replace or remove only Rush-generated hooks.
  • Preserve unmanaged hooks, including canonical Git LFS hooks, when there is no same-name repository hook.
  • Define and document collision behavior when both Rush and another tool manage the same hook.
  • Add integration coverage for:
    • git lfs install --local followed by rush update
    • rush update followed by git lfs install --local
    • repeated Azure-style checkout/install cycles in one worktree

At minimum, the Git-hooks documentation should state that Rush empties .git/hooks, explain the special LFS-hook-name behavior, and discuss checkout tools that invoke git lfs install.

Standard questions

Question Answer
@microsoft/rush globally installed version? Version selector; tested with Rush 5.180.0
rushVersion from rush.json? 5.180.0
useWorkspaces? true
Package manager pnpm 10.34.6
Operating system Linux
Node.js version 24.18.0
Git LFS versions 3.7.1 locally; 3.4.1 in Azure Pipelines
Would you consider contributing a PR? Yes
Linguagem predominante
TypeScript
Estrelas
6.5k
Forks
710
Merge médio
1d 13h
PRs com merge (30d)
45

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

  • Sem Dockerfile nem arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de microsoft/rushstack

Todas as issues de microsoft/rushstack

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.