On Sat, Aug 3, 2013 at 11:44 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > On Fri, Aug 2, 2013 at 8:53 PM, Duy Nguyen <pclouds@xxxxxxxxx> 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. > > Defining "valid" is a tricky business, though, as pid can and will > wrap around, Yes there is a chance that the old pid is not used for another process and it could get worse when that process is a daemon and runs forever. If we go the optimistic way, we could check mtime of auto-gc.pid. If it's older than a couple hours, ignore it and run gc anyway, assuming gc can't last longer than an hour or so. A more reliable way is save a unix socket instead of auto-gc.pid and send something over the socket to verify it's gc, but I think it's overkill. > and the directory could be shared on multiple machines. A > pid written by a process on one machine has no relation to any pid on > another machine. I worry less about this. It's not the right model to have two machines modify the same shared repository (gc --auto is only triggered when we think there are new objects) even though I think we support it. If it's two _scripts_ modifying the same repo, I don't care as this is more about user interaction. If it's two people modifying the same repo, it sounds like an insane setup and there may be more issues to worry about than gc --auto. -- Duy -- 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