1 |
On Wed, 24 Aug 2011 07:30:11 +0000 |
2 |
"Robin H. Johnson" <robbat2@g.o> wrote: |
3 |
|
4 |
> On Wed, Aug 24, 2011 at 12:44:57AM -0400, Matt Turner wrote: |
5 |
> > On Tue, Aug 23, 2011 at 10:30 PM, Donnie Berkholz |
6 |
> > <dberkholz@g.o> wrote: |
7 |
> > > On 15:49 Tue 23 Aug , Lance Albertson wrote: |
8 |
> > >> I think using the shortlog output is the sane solution otherwise |
9 |
> > >> you're just replicating what you do in the commit. |
10 |
> > > |
11 |
> > > It's not replication if users continue to use rsync; they won't |
12 |
> > > have commit info. |
13 |
> > |
14 |
> > Do we really want users to continue using rsync? Isn't git pull so |
15 |
> > much faster? What's the downside of users using git directly? |
16 |
> Bandwidth: Along the same lines, rsync will always be able to use less |
17 |
> bandwidth than Git, because none of the intermediate commits need to |
18 |
> be transfered. This will be esp. evident as a user tree gets older |
19 |
> (the amount of mtime/checksum metadata scales linearly with the size |
20 |
> of the tree, not the age of the tree. The actual file content |
21 |
> transfered scales linearly with the age of the tree). |
22 |
|
23 |
I tend not to agree here. With very rare updates, this is true indeed. |
24 |
But I guess that with daily or maybe even weekly updates, git should be |
25 |
able to consume less bandwidth because it doesn't need to check all |
26 |
unmodified files. |
27 |
|
28 |
-- |
29 |
Best regards, |
30 |
Michał Górny |