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

From: Kevin Willford <kewillf@microsoft.com>
Date: Sep 8, 2017, 20:02 UTC
Message-ID: <SN1PR21MB0014638E5D9CBFD0D9D85F10B7950@SN1PR21MB0014.namprd21.prod.outlook.com>
In-Reply-To: <xmqqvaktxawk.fsf@gitster.mtv.corp.google.com>

From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Friday, September 8, 2017 1:12 PM

Show 15 quoted lines

> Kevin Willford <kewillf@microsoft.com> writes:
> 
> > When using the sparse checkout feature the git reset command will add
> > entries to the index that will have the skip-worktree bit off but will
> > leave the working directory empty.  File data is lost because the index
> > version of the files have been changed but there is nothing that is in the
> > working directory.  This will cause the next status call to show either
> > deleted for files modified or deleting or nothing for files added.
> 
> Getting rid of sparseness may of course be one way to correct the
> discrepancy, but it is unclear to me if that is the best way to do
> so.  An alternative may be to add entries to the index that does
> have the bit on for paths that are meant to be skipped due to
> "sparse" thing, no?  Am I being naive, missing some reason why that
> would give us a worse result?

There are two cases that this is trying to solve.

1. reset mixed when there were files that were added

In this case the index will no longer have the entry at all because the reset is making the index look like before the file was added which didn't have it. When not using the sparse-checkout this is fine because the file is in the working directory and the reset didn't touch it. But using the sparse-checkout on that file and if the file was not in the working directory, the index gets reset and the entry for that file is gone and if we don't put the index version of the file before the reset into the working directory, then we have lost the content for that file

2. reset mixed when there were files modified

This case is similar but with modified files there is an entry in the index but it is getting changed to a previous version of the file. If we don't get the file on disk then the version of the file that, in the non sparse-checkout case, would be on disk is lost and cannot be recovered. So even if we turn on the skip-worktree bit for this entry and it doesn't show up in status calls, we lost the previous version of the file.