Subject: Re: RFC: Sparse checkout improvements

From: Marc Branchaud <[email-masked]>
Date: Wed, 28 Jul 2010 09:42:20 -0400

On 10-07-27 12:55 PM, [email-masked] wrote:
> On Tue, Jul 27, 2010 at 7:24 AM, Marc Branchaud <[email-masked]> wrote:
> 
>> * What's missing is a way to define named collections of paths
>> ("sparse-sets?") in .git/info/sparse-checkout, so that you can conveniently
>> checkout a particular subset of the working directory.  It would also be nice
>> to switch between different sparse-sets.
> 
> I pasted in a script I wrote to work with the sparse checkout feature.
> I'm not a scripting expert so it probably doesn't things incorrectly.
> It lets you create "modules" by adding sections to .gitmodules file at
> the root of the repository (or a file you specify). You can list them,
> switch/checkout between them, or reset back to normal:

That script looks like a great proof-of-concept.  I haven't tried it out yet,
but it seems to work along the lines of what I was thinking about.

I'd like to see most of this functionality folded into the standard git
commands, and maybe a new git-sparse command for managing sparse sets.

> [module "MyApp1"]
> 	<path1>
> 	<path2>
> 
> $ git module list
> MyApp1
> 
> $ git module checkout MyApp1
> 
> $ git module reset
> 
>> * It would also be good to have a way for a repo to define a default
>> sparse-set, so that a clone would only checkout that default.
> 
> Yes, this would be nice. Ideally what I would like is for there to be
> a clone option to specify a "module" (what I've been calling sparse
> sets). A first step could just clone the full repository with -n then
> do 'git module checkout <module>' (what my other scripts do to prepare
> archives).

I'd really prefer to see it as a configuration option for the remote
repository.  Let the remote tell me what the initial sparse set should be.

> Ideally, it would do some work on the server side to only
> send the objects needed for paths specified by the sparse set (but
> still allow me to commit and later push changes back).

I'm less interested in sparse fetching, so I'll stay out of that side of the
conversation.

		M.