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