Re: [PATCH 7/7] sparse-checkout: provide a new update subcommand

From: Derrick Stolee <stolee@gmail.com>
Date: Mar 16, 2020, 17:18 UTC
Message-ID: <137d9910-452b-9c96-b3a4-2b19053f6a67@gmail.com>
In-Reply-To: <CABPp-BE=VdSAfAWR_2KivXbGOYknhJ=4sbRjVPAS+URNgjLFPQ@mail.gmail.com>

On 3/16/2020 1:05 PM, Elijah Newren wrote:

Show 21 quoted lines

> On Sun, Mar 15, 2020 at 9:24 AM Derrick Stolee <stolee@gmail.com> wrote:
>>
>> On 3/14/2020 3:11 AM, Elijah Newren via GitGitGadget wrote:
>>> From: Elijah Newren <newren@gmail.com>
>>> +static int sparse_checkout_update(int argc, const char **argv)
>>> +{
>>> +     repo_read_index(the_repository);
>>> +     return update_working_directory(NULL);
>>> +}
>>> +
>>
>> Short and sweet! I suppose my earlier comment about whether
>> repo_read_index() was necessary is answered here. Perhaps it
>> should be part of update_working_directory()? (And pass a
>> repository pointer to it?)
> 
> Good question.  Is there a chance we want to make
> update_working_directory() available to other areas of git outside of
> sparse-checkout.c?  If so, potentially re-reading the index might not
> be friendly, but if sparse-checkout.c is going to remain the only
> caller then it probably makes sense to move it inside.

Minh had an interesting idea during side-conversations at the summit: have a way for an in-tree description of some sparse-checkout cones. The idea was to be able to automatically update the sparse-checkout while moving between commits that may have different dependency configurations. In the world of Office it would mean that there is some file ".sparse/word" that describes the directories required to build Word, and ".sparse/ppt" for building PowerPoint. Then, based on local Git config, we would see that we want our sparse-checkout cone to match the union of the directories in .sparse/word and .sparse/ppt. As we move HEAD, we would want to automatically update the sparse cone when those files change.

I'm working on a design document for how this idea would work, realistically, that I plan to share here and with the Office team to see if it is actually a helpful plan. I think it would reduce the performance cost of the hook we plan to use for this, and would reduce the investment needed for a project to adopt sparse-checkout.

All that is to say, yes we may want to add other callers to update_working_directory() outside of the sparse-checkout builtin. With that in mind, perhaps its name should reflect the fact that we are only updating it according to the sparse cone?

Thanks, -Stolee