Shallow Clone: Git Command Line vs Tower UI – Which Updates LFS Pointers Automatically?

Question

Goal
Determine how Tower Git handles Large File Storage (LFS) pointers after a shallow clone operation, and whether the tool should automatically update those pointers or rely on a manual fetch.
Background
Tower offers two documented shallow‑clone approaches: the Git command‑line flag --depth and the UI option “Shallow Clone.” In both cases, Tower retrieves LFS pointers but does not automatically fetch the full large files during the initial clone. The behavior of LFS pointer updates after the clone, especially across different Tower releases and operating systems, remains undocumented.
Uncertainty
It is unclear whether Tower should automatically perform an LFS fetch following a shallow clone, or leave that responsibility to the user. This decision impacts workflow consistency and repository completeness for developers who rely on LFS objects.
Questions

Does Tower automatically fetch LFS objects when a repository is shallow‑cloned via the UI “Shallow Clone” option?
Will a repository cloned with git clone --depth 1 trigger an automatic LFS pointer update when opened in Tower?
Should Tower provide an explicit setting to auto‑fetch LFS objects after any shallow clone?

Tasadduq Burney · Answer

Direct answer
Neither behavior is confirmed for Tower. Standard Git does not fetch LFS objects during git clone --depth 1; it stores pointer files and requires a separate fetch. Tower's UI “Shallow Clone” option is not verified to run git lfs fetch automatically, and opening an existing shallow clone in Tower does not by itself download missing large-file objects. Assume manual LFS fetch is required after either method until your Tower version and OS are confirmed.

Confirmed facts versus likely explanation
Confirmed: A shallow Git clone downloads history metadata and LFS pointers, not the large-file objects themselves. The checked-out files remain pointers until git lfs fetch or git lfs pull runs. Tower may bundle its own Git and LFS binaries, so command-line behavior on your workstation may not match Tower's UI behavior.
Likely explanation, not verified: Tower's “Shallow Clone” option probably passes --depth to the underlying clone command without appending an automatic LFS fetch step. No release notes or documentation reviewed here confirm automatic post-clone LFS fetching across Tower versions or operating systems.

Steps for this case

Clone the repository shallowly using the command line or Tower UI.
Run git lfs status to check whether tracked files are present.
Run git lfs ls-files --missing to list objects still not downloaded.
Run git lfs fetch or git lfs pull to retrieve large files for the checked-out refs.
Inspect Tower's clone dialog and preferences for an LFS fetch option; if none exists, treat manual fetch as required.

Safe verification commands
git lfs status
git lfs ls-files --missing
git lfs fetch --dry-run

Review required
Confirm the exact Tower version and operating system before relying on any UI-specific LFS behavior. Bundled tooling and release-specific changes can alter whether Tower fetches LFS objects after a shallow clone.

Shallow Clone: Git Command Line vs Tower UI – Which Updates LFS Pointers Automatically?

Goal

Background

Uncertainty

Questions

1 answer

Direct answer

Confirmed facts versus likely explanation

Steps for this case

Safe verification commands

Review required

Your perspective belongs here.

0 question comments