Module lfs_pre_push 

When a push needs the Git LFS upload, and the texts the parent prints around it. What: When a push needs the Git LFS upload, and the texts the parent prints around it. Why: Traditional hook files are unsupported, so the pre-push shim git lfs install writes cannot be relied on. Without an upload step a push publishes pointer files whose objects the LFS server never received. The wrapper therefore runs git-lfs push <remote> <refs> itself, as a child it owns, before it starts the push (lfs_upload.rs), only when the Git configuration holds LFS keys; the push carries no hook and no injected configuration, the wrapper never starts itself and writes no shell text (doc/planning/cli-git-no-self-invocation.md).

In TS you’d write (pseudocode):

if (usesLfs(snapshot) && !skipRequested(env)) { const code = await uploadObjects(plan); if (code) return code; }

Constants

LFS_PROGRAM

The program the upload runs, found on PATH as the shim git lfs install wrote found it.

SWITCH_NAME

The name the caller’s switch uses: -c hook.cli-git-lfs-pre-push.enabled=false skips the upload for one command, as it turned off the hook an earlier version put in effect.

Functions

failed_message

What: The explanation printed after git-lfs push failed. Why: git-lfs prints its own error first (a refused credential, an unreachable server, a missing local object); this text says what that means for the push and every way forward.

find_program

What: The first executable file named git-lfs in the directories of a PATH value, in order. Why: A stat per directory answers it without starting any process; an empty entry means the current directory, as PATH lookup treats it. The upload starts exactly this file, so the pre-check and the start agree about which git-lfs runs even though the child’s PATH leads with the real Git’s directory.

hook_switched_off

What: Whether the caller switched the upload off for this push, with -c hook.cli-git-lfs-pre-push.enabled=false among the global options or the same pair in GIT_CONFIG_COUNT/GIT_CONFIG_KEY_n/GIT_CONFIG_VALUE_n. Why: It is a documented way to push without the upload, so a missing git-lfs must not stop such a push. The last setting decides, as Git reads them, and -c options come after the environment’s pairs. A repository or account configuration file is not read: that would cost a Git start for every push; use --no-verify or GIT_LFS_SKIP_PUSH for a standing choice in the environment.

missing_program_message

What: The refusal printed when git-lfs is not on PATH. Why: Without the program the objects cannot be uploaded, and pushing anyway would publish pointers the server cannot serve; every valid way forward is named, including leaving LFS if the repository does not need it.

plan_failed_message

What: The refusal printed when the wrapper cannot work out which objects a push needs uploaded. Why: Running the push without an upload could publish pointers whose objects the server lacks, so the push is not started; every way forward is named.

program_on_path

Whether git-lfs is an executable file in one of the directories of a PATH value.

skip_requested

What: Whether the environment asks to skip the upload (GIT_LFS_SKIP_PUSH set to a true value). Why: git lfs push does not read that variable (only the hook form did), so the parent honours it, as the explanation texts promise.

uses_lfs

What: Whether a configuration entry of this repository, its worktree or the command line belongs to Git LFS. Why: git lfs install in an account writes filter.lfs.* to the global file, which every repository then sees, so a global key says nothing about this repository. The filter’s first run in a repository writes lfs.repositoryformatversion to its local file, and a server is named by lfs.url; one such key in the local, worktree or command scope is the sign that pushed pointers need their objects uploaded first, without making every repository of the machine an LFS repository.