Hi Derrick,
On Wed, Mar 16, 2022 at 9:34 PM Derrick Stolee <derrickstolee@xxxxxxxxxx> 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 :)
> 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
