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

From: Jacob Keller <jacob.keller@gmail.com>
Date: Sep 13, 2017, 01:39 UTC
Message-ID: <CA+P7+xqcAh4v4gDQOm-feYGc1EmFztAu0zMg2xnp8Gn4=BzkoQ@mail.gmail.com>
In-Reply-To: <SN1PR21MB001473733DAF15BC91C0E58AB7690@SN1PR21MB0014.namprd21.prod.outlook.com>

On Tue, Sep 12, 2017 at 4:30 PM, Kevin Willford <kewillf@microsoft.com> wrote:

Show 8 quoted lines

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