]>
Commit | Line | Data |
---|---|---|
94c0956b DS |
1 | git-sparse-checkout(1) |
2 | ====================== | |
3 | ||
4 | NAME | |
5 | ---- | |
9023535b | 6 | git-sparse-checkout - Reduce your working tree to a subset of tracked files |
94c0956b DS |
7 | |
8 | ||
9 | SYNOPSIS | |
10 | -------- | |
11 | [verse] | |
49cbad0e | 12 | 'git sparse-checkout <subcommand> [<options>]' |
94c0956b DS |
13 | |
14 | ||
15 | DESCRIPTION | |
16 | ----------- | |
17 | ||
9023535b EN |
18 | This command is used to create sparse checkouts, which means that it |
19 | changes the working tree from having all tracked files present, to only | |
20 | have a subset of them. It can also switch which subset of files are | |
21 | present, or undo and go back to having all tracked files present in the | |
22 | working copy. | |
23 | ||
24 | The subset of files is chosen by providing a list of directories in | |
25 | cone mode (which is recommended), or by providing a list of patterns | |
26 | in non-cone mode. | |
27 | ||
28 | When in a sparse-checkout, other Git commands behave a bit differently. | |
29 | For example, switching branches will not update paths outside the | |
30 | sparse-checkout directories/patterns, and `git commit -a` will not record | |
31 | paths outside the sparse-checkout directories/patterns as deleted. | |
94c0956b DS |
32 | |
33 | THIS COMMAND IS EXPERIMENTAL. ITS BEHAVIOR, AND THE BEHAVIOR OF OTHER | |
34 | COMMANDS IN THE PRESENCE OF SPARSE-CHECKOUTS, WILL LIKELY CHANGE IN | |
35 | THE FUTURE. | |
36 | ||
37 | ||
38 | COMMANDS | |
39 | -------- | |
40 | 'list':: | |
9023535b | 41 | Describe the directories or patterns in the sparse-checkout file. |
94c0956b | 42 | |
ba2f3f58 | 43 | 'set':: |
7316dc5f DS |
44 | Enable the necessary sparse-checkout config settings |
45 | (`core.sparseCheckout`, `core.sparseCheckoutCone`, and | |
46 | `index.sparse`) if they are not already set to the desired values, | |
47 | and write a set of patterns to the sparse-checkout file from the | |
ba2f3f58 EN |
48 | list of arguments following the 'set' subcommand. Update the |
49 | working directory to match the new patterns. | |
bab3c359 | 50 | + |
7316dc5f DS |
51 | To ensure that adjusting the sparse-checkout settings within a worktree |
52 | does not alter the sparse-checkout settings in other worktrees, the 'set' | |
53 | subcommand will upgrade your repository config to use worktree-specific | |
54 | config if not already present. The sparsity defined by the arguments to | |
55 | the 'set' subcommand are stored in the worktree-specific sparse-checkout | |
56 | file. See linkgit:git-worktree[1] and the documentation of | |
57 | `extensions.worktreeConfig` in linkgit:git-config[1] for more details. | |
58 | + | |
9023535b EN |
59 | When the `--stdin` option is provided, the directories or patterns are |
60 | read from standard in as a newline-delimited list instead of from the | |
61 | arguments. | |
a402723e | 62 | + |
ba2f3f58 | 63 | When `--cone` is passed or `core.sparseCheckoutCone` is enabled, the |
9023535b EN |
64 | input list is considered a list of directories. This allows for |
65 | better performance with a limited set of patterns (see 'CONE PATTERN | |
66 | SET' below). The input format matches the output of `git ls-tree | |
67 | --name-only`. This includes interpreting pathnames that begin with a | |
68 | double quote (") as C-style quoted strings. Note that the set command | |
69 | will write patterns to the sparse-checkout file to include all files | |
70 | contained in those directories (recursively) as well as files that are | |
71 | siblings of ancestor directories. This may become the default in the | |
72 | future; --no-cone can be passed to request non-cone mode. | |
73 | + | |
74 | When `--no-cone` is passed or `core.sparseCheckoutCone` is not enabled, | |
75 | the input list is considered a list of patterns. This mode is harder | |
76 | to use and less performant, and is thus not recommended. See the | |
77 | "Sparse Checkout" section of linkgit:git-read-tree[1] and the "Pattern | |
78 | Set" sections below for more details. | |
122ba1f7 | 79 | + |
ba2f3f58 EN |
80 | Use the `--[no-]sparse-index` option to use a sparse index (the |
81 | default is to not use it). A sparse index reduces the size of the | |
82 | index to be more closely aligned with your sparse-checkout | |
83 | definition. This can have significant performance advantages for | |
84 | commands such as `git status` or `git add`. This feature is still | |
85 | experimental. Some commands might be slower with a sparse index until | |
86 | they are properly integrated with the feature. | |
122ba1f7 DS |
87 | + |
88 | **WARNING:** Using a sparse index requires modifying the index in a way | |
89 | that is not completely understood by external tools. If you have trouble | |
90 | with this compatibility, then run `git sparse-checkout init --no-sparse-index` | |
91 | to rewrite your index to not be sparse. Older versions of Git will not | |
92 | understand the sparse directory entries index extension and may fail to | |
93 | interact with your repository until it is disabled. | |
94c0956b | 94 | |
2631dc87 | 95 | 'add':: |
9023535b EN |
96 | Update the sparse-checkout file to include additional directories |
97 | (in cone mode) or patterns (in non-cone mode). By default, these | |
98 | directories or patterns are read from the command-line arguments, | |
99 | but they can be read from stdin using the `--stdin` option. | |
2631dc87 | 100 | |
e2643353 | 101 | 'reapply':: |
5644ca28 EN |
102 | Reapply the sparsity pattern rules to paths in the working tree. |
103 | Commands like merge or rebase can materialize paths to do their | |
104 | work (e.g. in order to show you a conflict), and other | |
105 | sparse-checkout commands might fail to sparsify an individual file | |
106 | (e.g. because it has unstaged changes or conflicts). In such | |
107 | cases, it can make sense to run `git sparse-checkout reapply` later | |
108 | after cleaning up affected paths (e.g. resolving conflicts, undoing | |
109 | or committing changes, etc.). | |
ba2f3f58 EN |
110 | + |
111 | The `reapply` command can also take `--[no-]cone` and `--[no-]sparse-index` | |
112 | flags, with the same meaning as the flags from the `set` command, in order | |
113 | to change which sparsity mode you are using without needing to also respecify | |
114 | all sparsity paths. | |
5644ca28 | 115 | |
72918c1a | 116 | 'disable':: |
99dfa6f9 | 117 | Disable the `core.sparseCheckout` config setting, and restore the |
ba2f3f58 EN |
118 | working directory to include all files. |
119 | ||
120 | 'init':: | |
121 | Deprecated command that behaves like `set` with no specified paths. | |
122 | May be removed in the future. | |
123 | + | |
124 | Historically, `set` did not handle all the necessary config settings, | |
125 | which meant that both `init` and `set` had to be called. Invoking | |
126 | both meant the `init` step would first remove nearly all tracked files | |
127 | (and in cone mode, ignored files too), then the `set` step would add | |
128 | many of the tracked files (but not ignored files) back. In addition | |
129 | to the lost files, the performance and UI of this combination was | |
130 | poor. | |
131 | + | |
132 | Also, historically, `init` would not actually initialize the | |
133 | sparse-checkout file if it already existed. This meant it was | |
134 | possible to return to a sparse-checkout without remembering which | |
135 | paths to pass to a subsequent 'set' or 'add' command. However, | |
136 | `--cone` and `--sparse-index` options would not be remembered across | |
137 | the disable command, so the easy restore of calling a plain `init` | |
138 | decreased in utility. | |
72918c1a | 139 | |
94c0956b DS |
140 | SPARSE CHECKOUT |
141 | --------------- | |
142 | ||
9023535b EN |
143 | "Sparse checkout" allows populating the working directory sparsely. It |
144 | uses the skip-worktree bit (see linkgit:git-update-index[1]) to tell Git | |
145 | whether a file in the working directory is worth looking at. If the | |
146 | skip-worktree bit is set, and the file is not present in the working tree, | |
147 | then its absence is ignored. Git will avoid populating the contents of | |
148 | those files, which makes a sparse checkout helpful when working in a | |
149 | repository with many files, but only a few are important to the current | |
150 | user. | |
94c0956b DS |
151 | |
152 | The `$GIT_DIR/info/sparse-checkout` file is used to define the | |
153 | skip-worktree reference bitmap. When Git updates the working | |
154 | directory, it updates the skip-worktree bits in the index based | |
155 | on this file. The files matching the patterns in the file will | |
156 | appear in the working directory, and the rest will not. | |
157 | ||
ba2f3f58 EN |
158 | To enable the sparse-checkout feature, run `git sparse-checkout set` to |
159 | set the patterns you want to use. | |
72918c1a DS |
160 | |
161 | To repopulate the working directory with all files, use the | |
162 | `git sparse-checkout disable` command. | |
163 | ||
879321eb DS |
164 | |
165 | FULL PATTERN SET | |
166 | ---------------- | |
94c0956b DS |
167 | |
168 | By default, the sparse-checkout file uses the same syntax as `.gitignore` | |
169 | files. | |
170 | ||
171 | While `$GIT_DIR/info/sparse-checkout` is usually used to specify what | |
172 | files are included, you can also specify what files are _not_ included, | |
173 | using negative patterns. For example, to remove the file `unwanted`: | |
174 | ||
175 | ---------------- | |
176 | /* | |
177 | !unwanted | |
178 | ---------------- | |
179 | ||
94c0956b | 180 | |
879321eb DS |
181 | CONE PATTERN SET |
182 | ---------------- | |
183 | ||
184 | The full pattern set allows for arbitrary pattern matches and complicated | |
185 | inclusion/exclusion rules. These can result in O(N*M) pattern matches when | |
186 | updating the index, where N is the number of patterns and M is the number | |
187 | of paths in the index. To combat this performance issue, a more restricted | |
7aa9ef2f | 188 | pattern set is allowed when `core.sparseCheckoutCone` is enabled. |
879321eb DS |
189 | |
190 | The accepted patterns in the cone pattern set are: | |
191 | ||
192 | 1. *Recursive:* All paths inside a directory are included. | |
193 | ||
194 | 2. *Parent:* All files immediately inside a directory are included. | |
195 | ||
196 | In addition to the above two patterns, we also expect that all files in the | |
197 | root directory are included. If a recursive pattern is added, then all | |
198 | leading directories are added as parent patterns. | |
199 | ||
200 | By default, when running `git sparse-checkout init`, the root directory is | |
201 | added as a parent pattern. At this point, the sparse-checkout file contains | |
202 | the following patterns: | |
203 | ||
204 | ---------------- | |
205 | /* | |
206 | !/*/ | |
207 | ---------------- | |
208 | ||
209 | This says "include everything in root, but nothing two levels below root." | |
d2e65f4c DS |
210 | |
211 | When in cone mode, the `git sparse-checkout set` subcommand takes a list of | |
212 | directories instead of a list of sparse-checkout patterns. In this mode, | |
213 | the command `git sparse-checkout set A/B/C` sets the directory `A/B/C` as | |
214 | a recursive pattern, the directories `A` and `A/B` are added as parent | |
215 | patterns. The resulting sparse-checkout file is now | |
879321eb DS |
216 | |
217 | ---------------- | |
218 | /* | |
219 | !/*/ | |
220 | /A/ | |
221 | !/A/*/ | |
222 | /A/B/ | |
223 | !/A/B/*/ | |
224 | /A/B/C/ | |
225 | ---------------- | |
226 | ||
227 | Here, order matters, so the negative patterns are overridden by the positive | |
228 | patterns that appear lower in the file. | |
229 | ||
230 | If `core.sparseCheckoutCone=true`, then Git will parse the sparse-checkout file | |
231 | expecting patterns of these types. Git will warn if the patterns do not match. | |
232 | If the patterns do match the expected format, then Git will use faster hash- | |
233 | based algorithms to compute inclusion in the sparse-checkout. | |
234 | ||
de11951b DS |
235 | In the cone mode case, the `git sparse-checkout list` subcommand will list the |
236 | directories that define the recursive patterns. For the example sparse-checkout | |
237 | file above, the output is as follows: | |
238 | ||
239 | -------------------------- | |
240 | $ git sparse-checkout list | |
241 | A/B/C | |
242 | -------------------------- | |
243 | ||
190a65f9 DS |
244 | If `core.ignoreCase=true`, then the pattern-matching algorithm will use a |
245 | case-insensitive check. This corrects for case mismatched filenames in the | |
246 | 'git sparse-checkout set' command to reflect the expected cone in the working | |
247 | directory. | |
248 | ||
55dfcf95 DS |
249 | When changing the sparse-checkout patterns in cone mode, Git will inspect each |
250 | tracked directory that is not within the sparse-checkout cone to see if it | |
251 | contains any untracked files. If all of those files are ignored due to the | |
252 | `.gitignore` patterns, then the directory will be deleted. If any of the | |
253 | untracked files within that directory is not ignored, then no deletions will | |
254 | occur within that directory and a warning message will appear. If these files | |
255 | are important, then reset your sparse-checkout definition so they are included, | |
256 | use `git add` and `git commit` to store them, then remove any remaining files | |
257 | manually to ensure Git can behave optimally. | |
258 | ||
4fd683b6 DS |
259 | |
260 | SUBMODULES | |
261 | ---------- | |
262 | ||
e7d7c732 EN |
263 | If your repository contains one or more submodules, then submodules |
264 | are populated based on interactions with the `git submodule` command. | |
265 | Specifically, `git submodule init -- <path>` will ensure the submodule | |
266 | at `<path>` is present, while `git submodule deinit [-f] -- <path>` | |
267 | will remove the files for the submodule at `<path>` (including any | |
268 | untracked files, uncommitted changes, and unpushed history). Similar | |
269 | to how sparse-checkout removes files from the working tree but still | |
270 | leaves entries in the index, deinitialized submodules are removed from | |
271 | the working directory but still have an entry in the index. | |
272 | ||
273 | Since submodules may have unpushed changes or untracked files, | |
274 | removing them could result in data loss. Thus, changing sparse | |
275 | inclusion/exclusion rules will not cause an already checked out | |
276 | submodule to be removed from the working copy. Said another way, just | |
277 | as `checkout` will not cause submodules to be automatically removed or | |
278 | initialized even when switching between branches that remove or add | |
279 | submodules, using `sparse-checkout` to reduce or expand the scope of | |
280 | "interesting" files will not cause submodules to be automatically | |
281 | deinitialized or initialized either. | |
282 | ||
283 | Further, the above facts mean that there are multiple reasons that | |
284 | "tracked" files might not be present in the working copy: sparsity | |
285 | pattern application from sparse-checkout, and submodule initialization | |
286 | state. Thus, commands like `git grep` that work on tracked files in | |
287 | the working copy may return results that are limited by either or both | |
288 | of these restrictions. | |
4fd683b6 DS |
289 | |
290 | ||
94c0956b DS |
291 | SEE ALSO |
292 | -------- | |
293 | ||
294 | linkgit:git-read-tree[1] | |
295 | linkgit:gitignore[5] | |
296 | ||
297 | GIT | |
298 | --- | |
299 | Part of the linkgit:git[1] suite |