Re: git-index-pack really does suck..
- From
- David Lang <david.lang@digitalinsight.com>
- Date
- Apr 3, 2007, 22:36 UTC
- Message-ID
- <Pine.LNX.4.63.0704031532390.21680@qynat.qvtvafvgr.pbz>
- In-Reply-To
- <alpine.LFD.0.98.0704031836350.28181@xanadu.home>
On Tue, 3 Apr 2007, Nicolas Pitre wrote:
Show 11 quoted lines
> On Tue, 3 Apr 2007, Linus Torvalds wrote: > >> I don't care *what* it is conditional on, but your arguments suck. You >> claim that it's not a normal case to already have the objects, when it >> *is* a normal case for alternates, etc. >> >> I don't understand why you argue against hard numbers. You have none of >> your own. > > Are hard numbers like 7% overhead (because right now that's all we have) > really worth it against bad _perceptions_?
plus 1s overhead on what's otherwise a noop command.
Show 10 quoted lines
> The keeping of fetched packs broke that presumption of trust towards > local objects and it opened a real path for potential future attacks. > Those attacks are still fairly theoretical of course. But for how > _long_? Do we want GIT to be considered backdoor prone in a couple > years from now just because we were obsessed by a 7% CPU overhead? > > I think we have much more to gain by playing it safe and being more > secure and paranoid than trying to squeeze some CPU cycles out of an > operation that is likely to ever be bounded by network speed for most > people.
this is why -paranoid should be left on for network pulls, but having it on for the local uses means that the cost isn't hidden in the network limits isn't good.
David Lang