Skip to main content

Module lfs_pre_push

Module lfs_pre_push 

Source
Expand description

The Git LFS upload before a push, as a configuration hook the wrapper puts in effect for its own pushes. What: The Git LFS upload before a push, run as a supported pre-push configuration hook the wrapper puts in effect for its own pushes, and the git cli-git lfs-pre-push entry that hook starts. 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 adds hook.cli-git-lfs-pre-push.event=pre-push and a command naming itself to every real push it starts, only when the Git configuration holds LFS keys. Git runs that hook with its own arguments (<remote> <url>) and ref-update lines on standard input, before it sends anything, and a non-zero status stops the push; this module adds no copy of that computation.

In TS you’d write (pseudocode):

const args = usesLfs(snapshot) ? [...lfsHookArguments(executable), ...pushArguments] : pushArguments;

Constants§

HOOK_ENTRY
The management words the injected hook command starts the wrapper with.
HOOK_NAME
The friendly name of the injected hook; hook.<name>.enabled=false on the command line turns it off.

Functions§

failed_message
What: The explanation printed after git-lfs pre-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.
hook_arguments
What: The four global-option tokens that put the LFS hook in effect for one Git process. Why: The hook command names the running executable, so an upgraded or moved wrapper never leaves a stale path in the repository configuration; nothing is written to any configuration file.
hook_entry_arguments
What: The arguments after cli-git lfs-pre-push, when the invocation is the hook entry. Why: The entry is started by Git with exactly the management words and then <remote> <url>; anything else, such as global options in front, is an ordinary invocation.
missing_program_message
What: The refusal printed when git-lfs cannot be started. 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.
run_hook_entry
What: The hook entry: run git-lfs pre-push and print diagnostics on standard error. Why: Git starts this through the injected hook.cli-git-lfs-pre-push.command with <remote> <url> and the update lines on standard input.
run_with_program
What: Run program pre-push <arguments> with this process’s standard streams and report Git’s verdict for the hook. Why: Standard input carries the ref-update lines Git computed, so the child inherits it untouched; only a failure to start or a non-zero status adds this wrapper’s explanation, and the child’s status is the hook’s status.
shell_quote
What: Quote operating-system text as one word of a POSIX shell command. Why: Git runs a hook.<name>.command that holds a space through sh -c, so a path with spaces or quotes must stay one word; single quotes keep every byte literal, and an embedded single quote is closed, escaped and reopened.
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.
with_lfs_hook
What: Put the LFS hook in front of a Git command line. Why: Global options may precede the subcommand, so the hook definition goes first and a -c the caller wrote after it (for example -c hook.cli-git-lfs-pre-push.enabled=false) still wins.