Victoria Dye <vdye@xxxxxxxxxx> writes: >> +* Commands behaving the same regardless of high-level use-case >> + >> + * commands that only look at files within the sparsity specification >> + >> + * status >> + * diff (without --cached or REVISION arguments) >> + * grep (without --cached or REVISION arguments) > > 'status' and 'diff' currently show information about untracked files outside > the working tree (since, not being in the index, they don't have a > 'SKIP_WORKTREE' to use). Should that change with the proposed '--restrict' > option? Most likely not. When sparsity specification is in effect, as you said elsewhere in your response, no files, whether tracked or untrcked, should exist that are outside your area of interest. Their presence should be reported as anomalies by "git status". Unless the command is being run with the "-uno" option, that is. > - 'switch', 'checkout' (switch-like), and 'read-tree -m' block the operation > & advise on how to clean up the modified files to re-align with the > sparsity patterns. > - 'reset --hard' silently drops the modified file and resets the > 'SKIP_WORKTREE' bit on the corresponding index entry. > > With the exception of 'reset --hard' (aggressively and unconditionally > cleaning the worktree & index is an important aspect of the command, IMO), > I'd personally like to see commands in this category align with the behavior > of 'switch' where they don't already. Regardless of what we decide, though, > I think it's probably worth documenting the "modified outside of sparsity > patterns" case. True. I agree on both counts. > Also, 'read-tree' (no args) doesn't apply the 'SKIP_WORKTREE' bit to *any* > of the entries it reads into the index. Having all of your files suddenly > appear "deleted" probably isn't desired behavior, so it might be a good > candidate for the "Known bugs" section. I would imagine that it actually is OK to say that it is the responsibility of whoever invokes read-tree the plumbing command to reapply the skip-worktree bits and/or collapse the index entries outside the area of interest into trees afterwards. >> +* Commands that differ for behavior A vs. behavior B: >> + >> + * commands that make modifications: > > nit: "make modifications" -> "make modifications to the index"? That clarification actually raises an interesting question. Do we want three level distinction, i.e. different behaviour between commands that touch and do not touch the working tree, between those that touch and do not touch the index, and between those that touch and do not touch the commit? As the index is merely a way to express what the user did to eventually create the next tree to be recorded in the commit, my gut feeling is that it may be easier to understand if we treated the working tree and the index at the same level, actually. I.e. if grepping in the working tree of a sparse checkout does not find a match outside the cones of interest, it may make sense to do the same at least by default in "grep --cached" mode. If I understand Stolee's write-up on the use case of those in the camp B, they are more aware of the larger whole and expect to see hits outside the area they have checkout when running "grep HEAD". But in their use case, they do not touch (only look) the area outside their cone of interest, so if we limit the operation to their cone of interest by default for working tree, the same default probably should apply equally for an operation that inspect the index.
