On Sun, Apr 4, 2010 at 1:24 AM, Robin H. Johnson <robbat2@g.o> wrote:
> thin manifest:
> --------------
> No news, research here in list and see about it.
>

Just sent a mail to this list about this.

> sparse trees:
> -------------
> Upstream is done and released now, somebody needs to test it.
>

I just tried this with 1.7.0.4. The procedure to use it is as follows:

git clone [uri] [dir]
cd [dir]
git config core.sparsecheckout true
echo [list of directories and files] > .git/info/sparse-checkout
git read-tree -m -u HEAD

So essentially, you have to fetch the entire clone; and filtering is
only done on the file checkout side. We save on local checkout space,
but bandwidth used is the same.

At this point you have a checkout with only the dirs/files you listed.
You can only edit files/directories that you have checked out (and
commit/push). However, you can add *new* directories and files as you
like (and commit/push). Such new files/dirs will stick around until
you run another `git read-tree -m -u HEAD`. If you add a new
file/directory with the *same name* as an existing file/directory,
it'll get ignored.

If a directory or file is renamed; a pull will *not* update your
sparse-checkout list; directories will appear and disappear according
to the existing list. I also noticed some very strange behaviour when
`git read-tree` is combined with `git checkout`.

Note that this doesn't satisfy half the use of sparse trees; i.e.
quickly fetch only a subdirectory; make changes; push. However, I
suspect that would be extremely difficult to implement given git's
architecture.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team