1 |
Peter Volkov posted on Thu, 02 Jun 2011 09:09:04 +0400 as excerpted: |
2 |
|
3 |
>> One of the huge benefits in using git would be really fast emerge |
4 |
>> --syncs. Not having some kind of system for migrating users to git |
5 |
>> seems like a lot of the benefits are lost. |
6 |
> |
7 |
> Is git faster then rsync? I've never done any checks but it'll be |
8 |
> surprising if it will. |
9 |
|
10 |
That's a question that has come up before. I don't know the answer... |
11 |
|
12 |
> Another useful feature of rsync is --exclude that |
13 |
> allows some categories to be excluded (for size and speed efficiency), |
14 |
> e.g. my servers don't need kde-* and games-*. |
15 |
|
16 |
Git has similar options in the form of the .git/info/exclude file at the |
17 |
(local) repository level, and .gitignore files at the subdir level (these |
18 |
are normally synced with the repo but of course can be excluded locally by |
19 |
the above repository level file, if desired). |
20 |
|
21 |
Patterns similar to those used by rsync --exclude are even supported. =:^) |
22 |
|
23 |
See also the git config core.excludefile command (git-config (1) manpage) |
24 |
and the gitignore (5) manpage. |
25 |
|
26 |
> Also taking into account |
27 |
> that we use portage tree on embedded devices where again both size and |
28 |
> speed really matters it looks like the answer on your question is |
29 |
> "permanently". |
30 |
|
31 |
With shallow checkouts, the size aspect is somewhat mitigated. However, |
32 |
it may be that there'd be three user sync options, adding git, to the |
33 |
current two (rsync and webrsync). |
34 |
|
35 |
IMO it'd be a real shame to not make the git sync option available to the |
36 |
user, as a number of projects have already discovered that real community |
37 |
involvement at the GOOD bug report and above level can increase |
38 |
dramatically after a switch to git, due to the vastly increased |
39 |
accessibility and ease of use of tools such as git bisect. |
40 |
|
41 |
But the *REAL* decison on whether git is ultimately made available at the |
42 |
user level or not will probably be infra's to make, based not on the |
43 |
above, but on the very practical question of whether Gentoo's mirror |
44 |
infrastructure can actually handle the git-pull load. After all, that's |
45 |
said to be the reason the CVS tree isn't made directly available to |
46 |
ordinary users today. Git should be better than CVS in that regard, but |
47 |
will it be good /enough/ as compared to the resources demanded by rsync, |
48 |
or not? That I don't know, tho I suspect infra and/or the git upgrade |
49 |
project already has a reasonably educated opinion on the matter. |
50 |
|
51 |
Of course, someone like Google donating enough hardware and bandwidth to |
52 |
"make it happen", based on, say, their use of Gentoo as a basis for |
53 |
ChromeOS, thus making a healthy Gentoo good for them too, might help infra |
54 |
with its decision. One can hope. =:^) |
55 |
|
56 |
-- |
57 |
Duncan - List replies preferred. No HTML msgs. |
58 |
"Every nonfree program has a lord, a master -- |
59 |
and if you use the program, he is your master." Richard Stallman |