Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#6,120 0 Kommentare 1 Reaktion 2 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@iclanton arbeitet bereits daran.

Seit 07.10.2026.

  • #6121 von @copilot-swe-agent — offen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

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
Vorherrschende Sprache
TypeScript
Sterne
6.5k
Forks
710
Ø Merge
1 T. 23 Std.
Gemergte PRs (30 T.)
47

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus microsoft/rushstack

Alle Issues in microsoft/rushstack

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.