Re: [PATCH v2 05/20] sparse-index: implement ensure_full_index()
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Mar 15, 2021, 23:52 UTC
- Message-ID
- <87eeggf00n.fsf@evledraar.gmail.com>
- In-Reply-To
- <c730cb8d-06ff-6f86-4eae-812472157327@gmail.com>
On Fri, Mar 12 2021, Derrick Stolee wrote:
Show 41 quoted lines
> On 3/12/2021 3:08 PM, Junio C Hamano wrote:
>> Derrick Stolee <stolee@gmail.com> writes:
>>
>>>> Ævar, the assumption that led to your e68237bb (tree.h API: remove
>>>> support for starting at prefix != "", 2021-03-08) closes the door
>>>> for this code rather badly. Please work with Derrick to figure out
>>>> what the best course of action would be.
>>>
>>> Thanks for pointing this out, Junio.
>>>
>>> My preference would be to drop "tree.h API: remove support for
>>> starting at prefix != """, but it should be OK to keep "tree.h API:
>>> remove "stage" parameter from read_tree_recursive()" (currently
>>> b3a078863f6), even though it introduces a semantic conflict here.
>>>
>>> Since I haven't seen my sparse-index topic get picked up by a
>>> tracking branch, I'd be happy to rebase on top of Ævar's topic if
>>> I can still set a non-root prefix.
>> I think all the clean-up value e68237bb has are on the calling side
>> (they no longer have to pass constant ("", 0) to the function), and
>> we could rewrite e68237bb by
>>
>> - renaming "read_tree_recursive()" to "read_tree_at()", with the
>> non-empty prefix support.
>>
>> - creating a new function "read_tree()", which lacks the support
>> for prefix, as a thin-wrapper around "read_tree_at()".
>>
>> - modifying the callers of "read_tree_recursive()" changed by
>> e68237bb to instead call "read_tree()" (without prefix).
>>
>> to simplify majority of calling sites without losing functionality.
>>
>> Then your [05/20] can use the read_tree_at() to read with a prefix.
>>
>>
>> But that kind of details, I'd want to see you two figure out
>> yourselves.
>
> You've given us a great proposal. I'll wait for Ævar to chime in
> (and probably update his topic) before I submit a new version.I've re-rolled my series just now at https://lore.kernel.org/git/20210315234344.28427-1-avarab@gmail.com/ sorry for the delay.
You should be able to rebase easily on top of it, although note that the new read_tree_at() uses a strbuf, but is otherwise the same as the old read_tree_recursive().
Note that the pathspec can also be used to get to where read_tree_recursive() would have brought you. I haven't looked at whether there's reasons to convert in-tree (or this) code to pathspec use, or vice-versa convert some things that use pathspecs now (e.g. ls-tree with a path) to providing a prefix via the strbuf.