4 ms·

git clone --depth=1 is fast because it doesn't grab the full commits history but OP is getting at a specific singular file directly. It is neat, not aware of a

git clone --depth=1 is fast because it doesn't grab the full commits history but OP is getting at a specific singular file directly. It is neat, not aware of a git incantation so fine grained. Hope it gets built into Git directly.

merlincorey 3y ago
Ah, thank you for the clarification -- as far as I know that is indeed unique. It's a thimbleful sized shallow clone, one could say.
paulddraper 3y ago
You can do a shallow clone and partial checkout.
- verticalscaler 3y ago
  Cool! Why you gotta tease me like this without busting out a one liner? :) Gemini disagrees with you btw: Unfortunately, directly combining git shallow clone and git partial checkout to grab just one specific file isn't straightforward. Here's why: Shallow clone: This limits the downloaded commit history to a specific depth, but it still fetches all files involved in those commits. While reducing data, it wouldn't restrict files solely based on your needs. Partial checkout: This lets you specify which files to include in your working directory, but it requires a full clone initially. However, you have a few alternative approaches to achieve your goal: 1. Shallow clone + Sparse checkout: Use git clone --depth=<commit_depth> --single-branch=<branch> to shallow clone the specific branch and limit history. Create a .git/info/sparse-checkout file containing only the path to the desired file. Run git read-tree -u to update the index based on the sparse-checkout file. This method downloads a limited history and only keeps the specified file in your working directory. 2. Partial clone with server support (limited availability): Check if the server supports partial clones (currently implemented on Github and some Gitlab self-hosted instances). Use git clone --filter=blob:none <url> for a "blobless" clone that only contains file content, no history or directory structure. Add the desired file path to the .git/info/sparse-checkout file and run git read-tree -u as before. This approach minimizes downloaded data but requires server support and won't work everywhere.

merlincorey 3y ago

Ah, thank you for the clarification -- as far as I know that is indeed unique. It's a thimbleful sized shallow clone, one could say.

paulddraper 3y ago

You can do a shallow clone and partial checkout.

verticalscaler 3y ago
Cool! Why you gotta tease me like this without busting out a one liner? :) Gemini disagrees with you btw: Unfortunately, directly combining git shallow clone and git partial checkout to grab just one specific file isn't straightforward. Here's why: Shallow clone: This limits the downloaded commit history to a specific depth, but it still fetches all files involved in those commits. While reducing data, it wouldn't restrict files solely based on your needs. Partial checkout: This lets you specify which files to include in your working directory, but it requires a full clone initially. However, you have a few alternative approaches to achieve your goal: 1. Shallow clone + Sparse checkout: Use git clone --depth=<commit_depth> --single-branch=<branch> to shallow clone the specific branch and limit history. Create a .git/info/sparse-checkout file containing only the path to the desired file. Run git read-tree -u to update the index based on the sparse-checkout file. This method downloads a limited history and only keeps the specified file in your working directory. 2. Partial clone with server support (limited availability): Check if the server supports partial clones (currently implemented on Github and some Gitlab self-hosted instances). Use git clone --filter=blob:none <url> for a "blobless" clone that only contains file content, no history or directory structure. Add the desired file path to the .git/info/sparse-checkout file and run git read-tree -u as before. This approach minimizes downloaded data but requires server support and won't work everywhere.