From: Marc Branchaud <marcnarc@xiplink.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Alex <ajb44.geo@yahoo.com>, git@vger.kernel.org
Subject: RFC: Sparse checkout improvements (was: Re: question (possibly) on git subtree/submodules)
Date: Tue, 27 Jul 2010 10:24:13 -0400 [thread overview]
Message-ID: <4C4EEC0D.2070105@xiplink.com> (raw)
In-Reply-To: <m3bp9tks6e.fsf@localhost.localdomain>
On 10-07-27 08:48 AM, Jakub Narebski wrote:
> Alex <ajb44.geo@yahoo.com> writes:
>
>> Chris Packham <judge.packham <at> gmail.com> writes:
>>
>>> The short answer is no. Nothing git has currently will let you clone a
>>> subset of files.
>>
>> Isn't that what 'sparse checkout' does?
>> (http://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_sparse_checkout)
>
> No, 'sparse checkout' is only about checkout, i.e. the working area.
> You still have all objects in repository, only part of tree (part of
> project / repository) is not checked out, not present on disk as
> files.
There's no such thing as a "sparse fetch" but you can do something like
git clone -n git://there/foo.git
cd foo
then
git checkout origin/<branch> -- <paths...>
or
git config core.sparseCheckout true
[ Add paths to .git/info/sparse-checkout ]
git checkout <branch>
but it's fairly inconvenient for day-to-day work. Also, putting a
.git/info/sparse-checkout file in a public repo seems of limited use.
So IMHO the current sparse-checkout feature is pretty bare-bones and could
use some meat. Here's some thoughts:
* 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.
* 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.
* I also think that core.sparseCheckout should be true by default, and git
should impose no sparseness if .git/info/sparse-checkout is missing or empty.
Comments?
M.
next prev parent reply other threads:[~2010-07-27 14:24 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 ` Marc Branchaud [this message]
2010-07-27 16:55 ` RFC: Sparse checkout improvements (was: Re: question (possibly) on git subtree/submodules) skillzero
2010-07-28 13:42 ` RFC: Sparse checkout improvements Marc Branchaud
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=4C4EEC0D.2070105@xiplink.com \
--to=marcnarc@xiplink.com \
--cc=ajb44.geo@yahoo.com \
--cc=git@vger.kernel.org \
--cc=jnareb@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).