Kevin Willford <kewi...@microsoft.com> writes:
> 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
I do not quite understand this argument. If you do
edit $path
git add $path
rm $path
git reset
for a $path that is not involved in the sparse thing, the version
that was previously indexed will be lost, but that is fine---the
user said that version is expendable by saying "reset".
How would that be different when the $path were not to be
materialized in the working tree due to sparseness? Where did that
"blob" object in the index immediately before you called "reset"
came from, and why do you say that the user does *not* consider that
one expendable, unlike the case for non-sparse path example above?
I suspect that a similar reasoning would apply to your 2., but I
didn't think it through.
The possible misconception, which I perceive in both of these, is
that you are somehow disagreeing with this basic assumption: by
saying "git reset [<tree-ish>]", the user is telling us that the
version in the index, even if that is different from HEAD,
<tree-ish>, or the file in the working tree, is *unwanted* and be
replaced with the one in HEAD (or <tree-ish> when given). Touching
the working tree files upon "git reset" is the last thing the user
expects to happen.
