From: Marc Branchaud Date: Wed, 28 Jul 2010 13:42:20 GMT Subject: Re: RFC: Sparse checkout improvements Message-ID: <4C5033BC.5020002@xiplink.com> In-Reply-To: On 10-07-27 12:55 PM, skillzero@gmail.com wrote: > On Tue, Jul 27, 2010 at 7:24 AM, Marc Branchaud 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"] > > > > $ 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 ' (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.