Re: [RFC PATCH 1/1] mv: integrate with sparse-index
- From
Derrick Stolee <derrickstolee@github.com>
- Date
- Mar 21, 2022, 19:45 UTC
- Message-ID
- <b64c1805-dff9-3fd3-1e5e-84bd68d4b058@github.com>
- In-Reply-To
- <xmqq8rt3xgmb.fsf@gitster.g>
On 3/21/2022 3:14 PM, Junio C Hamano wrote:
Show 28 quoted lines
> Derrick Stolee <derrickstolee@github.com> writes:
>
>>>> Another tool that may help you here is 'git ls-files --sparse -t'. It lists
>>>> the files in the index and their "tags" ('H' is "normal" tracked files, 'S'
>>>> is SKIP_WORKTREE, etc. [4]), which can help identify when a file you'd
>>>> expect to be SKIP_WORKTREE is not and vice versa.
>>>
>>> Wonderful.
>>>
>>> Quite honestly, because the code will most likely compile correctly
>>> if you just remove the unconditional "we first expand the in-core
>>> index fully" code, and because the "sparse index" makes the existing
>>> index walking code fail in unexpected and surprising ways, I
>>> consider it unsuitably harder for people who are not yet familiar
>>> with the system. Without a good test coverage (which is hard to
>>> give unless you are familiar with the code being tested X-<), one
>>> can easily get confused and lost.
>>
>> Certainly, 'git mv' is looking to be harder than expected, but there
>> is a lot of interesting exploration happening in the process.
>
> Yeah, I know.
>
> I am suprised that it is harder than expected *to* *you*, though.
> After having seen a few other topics, I thought that you should know
> how deceptively easy to lose "require-full" and how hard to audit
> the code that may expect "a flat list of paths" in the in-core index
> ;-).I'm particularly surprised in how much 'git mv' doesn't work very well in the sparse-checkout environment already, which makes things more difficult than "just" doing the normal sparse index things.
It's good that we are discovering them and working to fix them.
Thanks, -Stolee