Duy Nguyen wrote: > Good point. I think that is because gc does not check if gc is already > running. Adding such a check should not be too hard. I think gc could > save its pid in $GIT_DIR/auto-gc.pid. The next auto-gc checks this, if > the pid is valid, skip auto-gc. Check. I also talked about gc not catching SIGINT properly: I'm looking the issue. > Or you could just make a cron job to gc all repos every week and the > problem goes away ;-) Fundamentally, we need to fix these problems: 1. Don't make the repo unusable when a gc is running: I don't expect anything more than minor annoyances after your patch is checked in. 2. Improve the IO profile, so gc doesn't aggressively hammer out tiny fragmentations. For this, git-exproll.sh is definitely a step in the right direction. 3. Improve how gc fundamentally works, so we can minimize rebuilds and CPU time. jc's git merge-pack is interesting, but I'm not very hopeful about a naive incremental-packing. We need to keep the major undeltified objects near the top of the file, and build an idx sorted by SHA-1; mangling the offsets in the header after a packfile has been written is both complicated and dangerous (we might introduce subtle bugs corrupting the packfile), I think. I haven't thought about it hard enough though. We'll tackle these problems bit by bit in future patches. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html