Re: [PATCH] sparse-checkout.txt: new document with sparse-checkout directions

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 27, 2022, 16:07 UTC
Message-ID: <xmqqzgek7qd9.fsf@gitster.g>
In-Reply-To: <CABPp-BESkb=04vVnqTvZyeCa+7cymX7rosUW3rhtA02khMJKHA@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 8 quoted lines

> Oh, wow, that's something completely outside what I had considered.  I
> had viewed sparse-checkouts as splitting "tracked files" into two
> subsets.  As such, `--[no-]restrict` could only affect selecting
> whether the smaller or larger set of tracked files was of interest.
> From that viewpoint, untracked files seemed orthogonal, and thus there
> couldn't be such a thing as an "anamalous untracked file".
>
> But this idea is very interesting.  Hmm...

We need to design the behaviour of "git add" sensibly. Even we say "untracked files are just one class and there are two classes of tracked ones, those path of current interest and those that are uninteresting", we would need to say "'git add F' behaves this way if F would become 'tracked path of current interest' when added, but the command behaves this other way if F becomes 'tracked path that is not interesting right now'". It may be cleaner to separate the untracked ones along the same line as the tracked ones.

Which in turn would mean that the skip-worktree bit cannot be the source of truth. Sparsity specification (either pattern matching or being in listed directories) authoritatively decides if a path is of the current interest or not. This is simply because untracked ones cannot have that bit ;-) We can treat the skip-worktree bit as mere implementation detail, a measure for optimization.

Show 6 quoted lines

> One thing that makes me a little leery about this path is whether we
> can consistently apply the scoped-to-sparse-specification rule for
> index operations.  For example:
>
>   * You previously agreed that `git format-patch` should ignore sparse
> specification and operate full tree.

It is not "are we focusing on subset when we talk about index" to begin with---format-patch is about a commit (or a series of commit), and you should view it as a member of the "log" family. Or the first half of "rebase/cherry-pick" (the other half being "am"), which should be full-tree, I would think.

>   * `git apply --cached $PATCH` only updates the index, and you
> suggested in an alternate email that apply should operate full-tree
> (at least with --index or without --cached, but I assume by extension
> it probably also applies with --cached).

I have not thought about "apply --cached". Just like merge-tree can merge without a working tree, "apply --cached" should be able to serve as a foundation to apply a series out of lore archive and create a topic branch without a working tree.

Show 12 quoted lines

>   * What if someone runs `git diff --cached` just before that commit?
> Do we scope the diff to only those paths within the sparse
> specification?
>   * What if someone runs `git status` just before that commit?  Do we
> only show staged changes within the sparse specification?
>
> It feels like "git grep --cached" is perhaps the next thing along this
> sequence, and I don't see a clear line where to draw that we should
> limit things to the sparse specification for the index while treating
> the other operations as full tree; it seems like something feels
> broken or inconsistent in this sequence of commands if we attempt to
> do so.

OK, it seems that "--cached" has many cases that it wants to operate on full tree. I am in general more in favor of making things work on full tree, simply because I feel it would have less chance of going wrong, so defaulting to --no-restrict would be fine ;-)