Web lists-archives.com

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




On Tue, Sep 12, 2017 at 4:30 PM, Kevin Willford <kewillf@xxxxxxxxxxxxx> wrote:
>
> Sorry.  It was not in the sparse-checkout file.
> $ git config core.sparsecheckout true
> $ echo /i > .git/info/sparse-checkout
> $ git checkout -f
> was ran in the modified file case as well and "i" was the only file in the
> working directory before reset.
>


I'm assuming then that you mean that some file "m" is modified by the
commit, and do not mean to say that it has local modifications in the
working tree? That is not what I had inferred from earlier, so I was
very much confused.

In this example, the only file actually checked out is "i", as
everything else will have the skip-worktree bit set..?

So doing git reset HEAD~1 will reset the branch back one commit, and
now because of this reset is clearing the skip worktree flag, and
since you never had a copy of it checked out it is notified as
deleted, because it's no longer marked as skip-worktree?


I think the real fix is to stop having reset clear skip-worktree, no?

By definition if you do a sparse checkout, you're telling git "I only
care about the files in this sparse checkout, and do not concern me
with anything else"... So the proposed fix is "since git cleared the
skip-worktree flag, we should actually also copy the file out again."
but I think the real problem is that we're clearing skip worktree to
begin with?