1 |
On Sun, Apr 4, 2010 at 1:24 AM, Robin H. Johnson <robbat2@g.o> wrote: |
2 |
> thin manifest: |
3 |
> -------------- |
4 |
> No news, research here in list and see about it. |
5 |
> |
6 |
|
7 |
Just sent a mail to this list about this. |
8 |
|
9 |
> sparse trees: |
10 |
> ------------- |
11 |
> Upstream is done and released now, somebody needs to test it. |
12 |
> |
13 |
|
14 |
I just tried this with 1.7.0.4. The procedure to use it is as follows: |
15 |
|
16 |
git clone [uri] [dir] |
17 |
cd [dir] |
18 |
git config core.sparsecheckout true |
19 |
echo [list of directories and files] > .git/info/sparse-checkout |
20 |
git read-tree -m -u HEAD |
21 |
|
22 |
So essentially, you have to fetch the entire clone; and filtering is |
23 |
only done on the file checkout side. We save on local checkout space, |
24 |
but bandwidth used is the same. |
25 |
|
26 |
At this point you have a checkout with only the dirs/files you listed. |
27 |
You can only edit files/directories that you have checked out (and |
28 |
commit/push). However, you can add *new* directories and files as you |
29 |
like (and commit/push). Such new files/dirs will stick around until |
30 |
you run another `git read-tree -m -u HEAD`. If you add a new |
31 |
file/directory with the *same name* as an existing file/directory, |
32 |
it'll get ignored. |
33 |
|
34 |
If a directory or file is renamed; a pull will *not* update your |
35 |
sparse-checkout list; directories will appear and disappear according |
36 |
to the existing list. I also noticed some very strange behaviour when |
37 |
`git read-tree` is combined with `git checkout`. |
38 |
|
39 |
Note that this doesn't satisfy half the use of sparse trees; i.e. |
40 |
quickly fetch only a subdirectory; make changes; push. However, I |
41 |
suspect that would be extremely difficult to implement given git's |
42 |
architecture. |
43 |
|
44 |
-- |
45 |
~Nirbheek Chauhan |
46 |
|
47 |
Gentoo GNOME+Mozilla Team |