Module lfs_upload 

The parent’s bounded or interactive run of the Git LFS upload. What: The parent’s run of the Git LFS upload before a push: git-lfs push <remote> <refs> as one child it owns. Why: Without an upload step a push publishes pointer files whose objects the LFS server never received. The wrapper runs git-lfs push itself, so a failure is explained by the process that saw it and the push, which then carries no hook, is never started. Nothing here starts the wrapper, writes shell text or injects Git configuration (doc/planning/cli-git-no-self-invocation.md). What to upload is decided in lfs_upload_plan. The child sees what the caller gave Git: the global -c options travel as GIT_CONFIG_COUNT pairs, --git-dir, --work-tree and --namespace as their variables, -C as the working directory, and the real Git’s directory leads its PATH so a git it starts is never the wrapper while git-lfs itself is the one the caller’s PATH finds first.

In TS you’d write (pseudocode):

const code = await spawn(findProgram(env.PATH), plan.arguments(), { env: withPrefix(env, globalPrefix), stdio: 'inherit' });

Functions

prefix_variables

What: The variables that carry the global options of a push into a child that reads Git’s configuration. Why: -c name=value becomes GIT_CONFIG_KEY_n/GIT_CONFIG_VALUE_n after any pairs the environment already holds (a -c without = is the boolean true), --git-dir, --work-tree and --namespace become GIT_DIR, GIT_WORK_TREE and GIT_NAMESPACE; -C is the working directory and is applied by the caller. No shell is involved, and an -c http.extraHeader=... or -c lfs.url=... reaches git-lfs as it reached the Git that used to run the hook.

run_upload_bounded

What: Run the upload as a bounded child whose output is captured, and return the failed attempt to stop with, or nothing when it succeeded. Why: The auto-push records and shows a failed attempt’s output; the explanation is part of it. A stop by deadline says so, and a step the holder’s time budget left no time for is not started and says that instead.

run_upload_interactive

What: Run the upload as a child with the caller’s streams and return the status to stop with, or nothing when it succeeded. Why: The parent saw the child end, so it prints the explanation after the program’s own output; the push is not started. A signal sent to the wrapper is relayed to the child, so stopping the wrapper stops the upload. A push that also pushes submodules gets a notice, because their objects are not part of this upload.

submodule_notice

What: The notice for a push that also pushes submodules. Why: Git pushes a submodule’s commits itself; their LFS objects are not uploaded by the wrapper, and the pointer files would be published without them. Every way forward is named.