On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano <gits...@pobox.com> 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
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?
- ask interesting questions
- don't get distracted with shiny stuff - working code first
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