Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#6,120 0 commentaires 1 réaction 2 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@iclanton y travaille déjà.

Depuis le 7/10/2026.

  • #6121 par @copilot-swe-agent — ouverte

Évaluation

Cette issue n'a pas encore été évaluée.

Description

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
Langage dominant
TypeScript
Étoiles
6.5k
Forks
710
Merge moyen
1 j 13 h
PR mergées (30 j)
45

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

  • Aucun Dockerfile ni fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoft/rushstack

Toutes les issues de microsoft/rushstack

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.