Re: rsync deprecated but promoted?

> Dear diary, on Sun, Sep 25, 2005 at 09:06:37PM CEST, I got a letter
> where Martin Coxall <quasi@cream.org> told me that...
> 
>>On 25 Sep 2005, at 17:32, Zack Brown wrote:
>>
>>>Hi folks,
>>>
>>>When I use cogito, it gives a warning saying the rsync method is 
>>>deprecated and
>>>will be removed in the future. But when I visit kernel.org/git, the 
>>>page says to
>>>use an rsync URL with cg-clone.
>>>
>>>Maybe kernel.org should be updated?
>>>
>>
>>It does seem to be sending out a confusing message to us users too, 
>>since an initial clone of Linus's tree with rsync is on my machine 10x 
>>faster than an http clone, so it seems to be sending out something of a 
>>confused/confusing message re: rsync.
>>
>>Am I right in thinking it's because rsync didn't originally have pack 
>>support, but now it does, Petr has simply forgotten to deprecate the 
>>deprecation message?
> 
> 
> Nope. rsync always did packs, I actually un-deprecated it for the time
> period when HTTP didn't. The thing is, rsync is bad - it will happily
> put duplicate, redundant, and especially unwanted data to your
> repository, especially when the shared GIT repositories happen. HTTP and
> git-daemon are much better access methods in this regard - actually, I
> still like HTTP the most:
> 
> + Works everywhere - no special setup, no dedicated service, firewalls
> and proxies won't stop it
> + Works properly, i.e. only getting stuff you want, unlike rsync
> + Replicates packs setup - would be even better if it would kill objects
> and packs which the new pack makes redundant
> 
> 	It would be best to have some smarter git-prune-packed, which
> 	would process just a single pack. The other alternative would be
> 	that it would prune packs being subsets of other packs as well,
> 	but that scaled bad. I will write another mail about that.
> 
> - It is slow. Actually, I think it should be much faster for incremental
> fetches, and the initial fetch should take about the same time if you
> use packs. But the question is, did we already hit the limit? Are we
> using HTTP keepalive connections, do we parallelize the requests?
>