List Archive: gentoo-scm
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Sun, Apr 4, 2010 at 1:24 AM, Robin H. Johnson <firstname.lastname@example.org> 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 126.96.36.199. The procedure to use it is as follows:
git clone [uri] [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
Gentoo GNOME+Mozilla Team