RE: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.
- Date: Fri, 8 Sep 2017 20:02:33 +0000
- From: Kevin Willford <kewillf@xxxxxxxxxxxxx>
- Subject: RE: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.
From: Junio C Hamano [mailto:gitster@xxxxxxxxx]
Sent: Friday, September 8, 2017 1:12 PM
> Kevin Willford <kewillf@xxxxxxxxxxxxx> 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
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.