You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first cold clone of a repository pinned to a commit SHA fetches the full history of every branch. Shallow fetches require a ref name, and fetching a commit SHA at limited depth depends on a server option (`uploadpack.allowAnySHA1InWant`) that is not universally enabled, so CAS fetches all branches at full depth and resolves the SHA locally. Subsequent clones reuse the cached repository and never touch the network for the same commit.
62
+
63
+
</Since>
64
+
51
65
### Stack Usage
52
66
53
67
<Beforeversion="1.0.3">
@@ -195,9 +209,9 @@ When Terragrunt needs to clone a repository using the CAS it does the following,
195
209
196
210
For cold clones, where the content is not already in the CAS:
197
211
198
-
1. Terragrunt resolves the Git reference (branch/tag) to a commit hash
212
+
1. Terragrunt resolves the Git reference to a commit hash. Branch and tag refs resolve via `git ls-remote`. `ls-remote` lists named refs and does not resolve commit SHAs, so for SHA refs Terragrunt fetches the full history of every branch into the central Git store and resolves the SHA locally.
199
213
2. The tree related to the commit hash is not found in the CAS
200
-
3. Terragrunt clones the repository to a temporary directory
214
+
3. Terragrunt fetches the repository contents (shallow for branch/tag refs, full history for commit SHAs)
201
215
4. All blobs and trees required to reproduce the repository are extracted
202
216
5. Content is stored in the CAS, partitioned by hash prefix
203
217
6. The tree structure is read from the CAS and hard links are created to the target directory
@@ -206,7 +220,7 @@ For cold clones, where the content is not already in the CAS:
206
220
207
221
For warm clones, where the content is already in the CAS:
208
222
209
-
1. Terragrunt resolves the Git reference to a commit hash
223
+
1. Terragrunt resolves the Git reference to a commit hash. For commit-SHA refs the local central Git store answers without contacting the remote when the SHA is already cached.
210
224
2. CAS checks if the content exists
211
225
3. The tree structure is read directly from the CAS
212
226
4. Hard links are created from CAS to the target directory
Source URLs of the form `git::<url>?ref=<commit-sha>` now resolve through CAS. Previously these clones failed because Terragrunt asked the remote to look up the SHA as a symbolic reference, which Git servers don't support.
9
+
10
+
Both full SHAs (SHA-1 and SHA-256) and abbreviated SHAs are accepted. Abbreviated SHAs must disambiguate inside the repository, the same rule Git itself applies.
The first cold clone of a repository pinned to a commit SHA fetches the full history of every branch. Shallow fetches require a ref name, and fetching a commit SHA at limited depth depends on a server option (`uploadpack.allowAnySHA1InWant`) that is not universally enabled, so CAS fetches all branches at full depth and resolves the SHA locally. Subsequent clones reuse the cached repository and never touch the network for the same commit. Branch and tag refs continue to use the existing shallow path.
0 commit comments