Re: [RFC PATCH 1/1] mv: integrate with sparse-index

From: Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>
Date: Mar 16, 2022, 14:46 UTC
Message-ID: <CAJyCBORfAV_TV6DrOxgim4KtU9T-uTibOaQCsJZsi5_FQfci1Q@mail.gmail.com>
In-Reply-To: <675c7681-c495-727d-1262-ee8c6a5c8ce5@github.com>

Hi Derrick,

On Wed, Mar 16, 2022 at 9:34 PM Derrick Stolee <derrickstolee@github.com> wrote:

> The issue here is that this file is "untracked", not just outside
> of the sparse-checkout cone.

Thanks for the succinct explanation, it makes much more sense now :)

Show 9 quoted lines

> Instead, what about
>
>         git mv folder2/a deep/new
>
> since folder2/a is a tracked file, just not in the working tree
> since it is outside the sparse-checkout cone.
>
> (If it fails, then it should fail the same with and without the
> sparse index, which is what "test_sparse_match" is for.)

I tested this and it fails as expected with: "fatal: bad source, source=folder2/a, destination=deep/new"

> Thanks,
> -Stolee

Thanks for the reply above!

Other than that, I also have found another issue (probably), with

$ mkdir folder2 $ git mv folder2 deep

After these I do:

$ git status

And the output indicates that the index is updated with the following changes:

        renamed:    folder2/0/0/0 -> deep/folder2/0/0/0
        renamed:    folder2/0/1 -> deep/folder2/0/1
        renamed:    folder2/a -> deep/folder2/a

Nothing fails, which is not what I expected. What I expect is `git mv` will fail because it is being told to update a sparse-directory (which as I read the blogs and sparse-index.txt is taken as a sparse-directory entry) outside of the sparse-checkout cone. Unless `git mv` is supplied with `--sparse`, the command will do nothing but fail, no?

What confuses me more is that the `folder2`, which is present in the index but not in the working tree (due to sparse-checkout cone), seems to be "unlocked" and re-picked up by Git after `mkdir folder2` and move `folder2` into the cone area. And still, the files under `deep/folder2` are not present in the working tree (might be relevant to the previous context).

I haven't run the gdb to see into the process, I just get somehow confused by these discrepancies (seemingly to me). I think I should gdb into it though, getting some info here from people can also be really helpful :)

-- 
Thanks & Regards,
Shaoxuan