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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/16/2020 1:05 PM, Elijah Newren wrote:
> On Sun, Mar 15, 2020 at 9:24 AM Derrick Stolee <stolee@xxxxxxxxx> wrote:
>>
>> On 3/14/2020 3:11 AM, Elijah Newren via GitGitGadget wrote:
>>> From: Elijah Newren <newren@xxxxxxxxx>
>>> +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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux