On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > As long as we can reliably determine that it is safe to do so > without risking races, automatically cleaning .lock files is a good > thing to do. If the .lock file is a day old, it seems to me that it should be safe to call it stale. Can anyone "take the lock" if there is already a lock file? > Cleaning .keep files needs the same care and a bit more, though. > You of course have to be sure that no other concurrent process is in > the middle of doing something, but you also need to be sure that the > ".keep" file is not a marker created by the end user to say "keep > this pack, do not subject its contents to repacking" after a careful > repacking of the stable part of the history. For the keep files, I already drafted a script that looks inside the keep file, if it reads 'receive-pack [pid] [host]' it checks whether the hostname matches, and if so whether the pid matches a running process. Only if the host matches and the pid is dead we call it stale. Seems fairly conservative to me. Are there scenarios where we think this can misfire? m -- martin.langhoff@xxxxxxxxx - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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