Linus Torvalds wrote:I wonder if it makes sense to repack just the small incremental packs into a large (but still incremental) pack, rather than repacking the entire repository. Presumably that would be a lot faster than a full "git gc", while still giving you reasonably good packing (at least, if the threshold is set to a hugh enough number of small packs) and keeping things fast. That could run as a second phase of "git gc --auto" -- it should be quick enough to not be too terribly annoying since we're not running it in the background. Yeah, if you use the same repo for a long time, you'll accumulate a ton of medium-sized packs this way, but (a) that's much better than the situation we have today, and (b) it puts off the performance degradation for long enough that it becomes more reasonable to expect people to find out about running the full "git gc" in the meantime, or for git to further evolve to not need it. -Steve - 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
| Bart Van Assche | Re: Integration of SCST in the mainstream Linux kernel |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| David Miller | [GIT]: Networking |
| Radu Rendec | htb parallelism on multi-core platforms |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
