> From: Junio C Hamano [mailto:gitster@xxxxxxxxx] > Sent: Friday, September 8, 2017 9:18 PM > > Kevin Willford <kewillf@xxxxxxxxxxxxx> 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. > 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.
