On Wed, 24 Aug 2011 07:30:11 +0000
"Robin H. Johnson" <robbat2@g.o> wrote:

> On Wed, Aug 24, 2011 at 12:44:57AM -0400, Matt Turner wrote:
> > On Tue, Aug 23, 2011 at 10:30 PM, Donnie Berkholz
> > <dberkholz@g.o> wrote:
> > > On 15:49 Tue 23 Aug     , Lance Albertson wrote:
> > >> I think using the shortlog output is the sane solution otherwise
> > >> you're just replicating what you do in the commit.
> > >
> > > It's not replication if users continue to use rsync; they won't
> > > have commit info.
> > 
> > Do we really want users to continue using rsync? Isn't git pull so
> > much faster? What's the downside of users using git directly?
> Bandwidth: Along the same lines, rsync will always be able to use less
> bandwidth than Git, because none of the intermediate commits need to
> be transfered. This will be esp. evident as a user tree gets older
> (the amount of mtime/checksum metadata scales linearly with the size
> of the tree, not the age of the tree. The actual file content
> transfered scales linearly with the age of the tree).

I tend not to agree here. With very rare updates, this is true indeed.
But I guess that with daily or maybe even weekly updates, git should be
able to consume less bandwidth because it doesn't need to check all
unmodified files.

-- 
Best regards,
Michał Górny