From: Marc Branchaud <marcnarc@xiplink.com>
To: skillzero@gmail.com
Cc: Jakub Narebski <jnareb@gmail.com>, Alex <ajb44.geo@yahoo.com>,
git@vger.kernel.org
Subject: Re: RFC: Sparse checkout improvements
Date: Wed, 28 Jul 2010 09:42:20 -0400 [thread overview]
Message-ID: <4C5033BC.5020002@xiplink.com> (raw)
In-Reply-To: <AANLkTimJpmGqOogQ1HtN0zu0=tPK0C0kQuEkg4PeOqUh@mail.gmail.com>
On 10-07-27 12:55 PM, skillzero@gmail.com wrote:
> 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.
> [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.
prev parent reply other threads:[~2010-07-28 13:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-23 14:00 question (possibly) on git subtree/submodules Maurizio Vitale
2010-07-23 16:56 ` Chris Packham
2010-07-23 17:18 ` Jonathan Nieder
2010-07-23 18:35 ` Chris Packham
2010-07-27 10:56 ` Alex
2010-07-27 12:48 ` Jakub Narebski
2010-07-27 14:24 ` RFC: Sparse checkout improvements (was: Re: question (possibly) on git subtree/submodules) Marc Branchaud
2010-07-27 16:55 ` skillzero
2010-07-28 13:42 ` Marc Branchaud [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C5033BC.5020002@xiplink.com \
--to=marcnarc@xiplink.com \
--cc=ajb44.geo@yahoo.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=skillzero@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).