Re: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 15, 2017, 05:00 UTC
Message-ID: <xmqqh8w4y2se.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <SN1PR21MB0014031012AEC69CED27FADFB76F0@SN1PR21MB0014.namprd21.prod.outlook.com>

Kevin Willford <kewillf@microsoft.com> writes:

Show 9 quoted lines

> 1. Does this statement, "I only care about the files in this
> sparse checkout, and do not concern me with anything else", mean
> that git should not change files outside the sparse-checkout whether
> that be in the working directory or in the index?  Or does that only
> apply to the working directory and the index version of files can
> change to whatever git the git command would do without using
> sparse?  For example if I am doing a 'git reset HEAD~1'  should the
> version in the index of files outside the sparse not be changed or
> change to the HEAD~1 version with the skip-worktree bit on?

My understanding of the purpose of "sparse checkout" thing is that the user still wants to create correct whole-tree commit even the user does not have the whole-tree checkout. The object names for blobs recorded in the index that are meant to be included in the next commit MUST be the same as those that would be in the index when the "sparse" feature is not in use. "reset HEAD~1" should match the index entries to the tree entries in HEAD~1. So, the latter, I would think, among your two alternatives.

IOW, after "git reset HEAD~", if you drop the skip-worktree bit from all index entries, "git diff --cached HEAD" must say "there is no changes".

The only difference between the "sparse" and normal would be that, because the "sparse" user does not intend to change anything outside the "sparse" area, these paths outside her "sparse" area would not materialize on the filesystem. For the next "write-tree" out of the index to still write the correct tree out, the entries outside her "sparse" area in the index MUST match the tree of the commit she started working from.

> 2. How will this work with other git commands like merge, rebase,
> cherry-pick, etc.?  
> 3. What about when there is a merge conflict with a file that is outside
> the sparse checkout?

I would say, rather than forbidding such a merge, it should let her see and deal with the conflict by dropping the "this is outside the sparse area, so do not bother materializing it to the filesystem" bit, but tell her loudly what it did ("I checked out a half-merged file outside your sparse-checkout area because you'd need it while resolving the conflict"). By doing things that way, the user can decide if she wants to go ahead and complete the merge, even if the conflict is outside the area she is currently interested in, or postpone the merge and continue working on what she has been working on inside the narrowed-down area first.

I do not have a strong opinion whether the sparse-checkout configuration file should be adjusted to match when the command must tentatively bust the sparse checkout area; I'd imagine it can be argued either way.

Note that "sparse" is not my itch, and I would not be surprised if those who designed it may want it to work differently from my knee-jerk reaction in the previous two paragraphs, and I may even find such an alternative solution preferable.

But it is highly unlikely for any sensible solution would violate the basic premise, i.e. "the indexed contents will stay the same as the case without any 'sparse', so the next write-tree will do the right thing".