Gentoo Archives: gentoo-scm

From: Nirbheek Chauhan <nirbheek.chauhan@×××××.com>
To: "Robin H. Johnson" <robbat2@g.o>
Cc: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] Status
Date: Sun, 18 Apr 2010 12:43:28
Message-Id: h2l8b4c83ad1004180543redc1938ctf611ebce55aa374f@mail.gmail.com
In Reply to: Re: [gentoo-scm] Status by "Robin H. Johnson"
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