On Thu, 10 Jan 2008, Nicolas Pitre wrote:It's probably worth doing those statistics on some other projects. The kernel has for the last five+ years very much encouraged people to make series of small changes, so I would not be surprised if it turns out that the deltas for the kernel are smaller than average, if only because the whole development process has encouraged people to send in a series of ten patches rather than a single larger one. And there are basically *no* generated files in the kernel source repo. Maybe the difference to other repositories isn't huge, and maybe the kernel *is* a good test-case, but I just wouldn't take that for granted. Yes, delta's are bound to compress much less well than non-deltas, and especially for tree objects (which is a large chunk of them) they probably compress even less (because a big part of the delta is actually just the SHA1 changes), but if it's 11% on the kernel, it could easily be 25% on something else. Try with the gcc repo, especially the one that has deep delta chains (so it has even *more* deltas in relation to full objects than the kernel has) Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| David Miller | Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers. |
| Andrew Morton | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 010/196] Chinese: add translation of Codingstyle |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Felix von Leitner | socket api problem: can't bind an ipv6 socket to ::ffff:0.0.0.0 |
git: | |
