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

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?