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

From: Kevin Willford <kewillf@microsoft.com>
Date: Sep 9, 2017, 04:54 UTC
Message-ID: <SN1PR21MB00140C84DC02F3491F4E8469B76A0@SN1PR21MB0014.namprd21.prod.outlook.com>
In-Reply-To: <xmqqr2vgy2yt.fsf@gitster.mtv.corp.google.com>

Show 34 quoted lines

> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Friday, September 8, 2017 9:18 PM
> 
> Kevin Willford <kewillf@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 guess that I should have said files that were newly added, meaning they
are new files that were created and added in the previous commit.
 
I think that the difference is that the user explicitly removed the file. When
using sparse it is git that is causing the removal of the file.  For example
if I have /file in my spare-checkout file so that I am only working on the one
file.  The previous commit had new file2 added and I run a git reset HEAD~1.
I as the user do not expect that file2 just disappear, but yet that is what
happens.  So from you example above if I do.

	create $path
	git add $path
	git commit
	git checkout // where $path is not in the sparse-checkout
	git reset HEAD~1

$path will be gone yet I the user did not remove it. I guess you could argue that the user did when they specified their sparse-checkout and ran checkout but I wouldn't know what would go missing unless I ran a diff before the reset to see. There could have been X number of files created and added in the previous commit(s) and status after the reset would not report them and they are gone. So I could clone, setup sparse-checkout, checkout, reset HEAD~X and possibly lose data I didn't expect to.

In the modified case where the previous commits have modifications to files outside the sparse-checkout at least the status after the reset reports the file as deleted so the user sees that something has happened to it.

I suppose the entry could stay in the index with the skip-worktree bit on and not removed like it is now so that a git reset will only apply to the entries in the sparse-checkout? That seems like it would be changing the meaning of reset.

Show 12 quoted lines

> 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.
>

I agree with this when you are not dealing with a sparse-checkout. When using a sparse-checkout I expect git not to touch things outside of what I have specified in my sparse-checkout file. If it does, it should let me know or put my working directory in a state that is expected. Especially when it is changing the skip-worktree bits causing files outside the sparse-checkout to be reported incorrectly by status.