Re: RFC: Sparse checkout improvements

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Jul 28, 2010, 13:42 UTC
Message-ID: <4C5033BC.5020002@xiplink.com>
In-Reply-To: <AANLkTimJpmGqOogQ1HtN0zu0=tPK0C0kQuEkg4PeOqUh@mail.gmail.com>

On 10-07-27 12:55 PM, skillzero@gmail.com wrote:

Show 12 quoted lines

> On Tue, Jul 27, 2010 at 7:24 AM, Marc Branchaud <marcnarc@xiplink.com> 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.

Show 19 quoted lines

> [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.