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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html