When annex.freezecontent-command or annex.thawcontent-command is configured
but fails, prevent initialization.
This allows the user to fix their configuration and avoid crippled
filesystem detection entering an adjusted unlocked branch unexpectedly,
when they had been relying on the hooks working around their filesystems's
infelicities.
In the case of git-remote-annex, a failure of these hooks is taken to mean
the filesystem may be crippled, so it deletes the bundles objects and
avoids initialization. That might mean extra work, but only in this edge
case where the hook is misconfigured. And it keeps the command working
for cloning even despite the misconfiguration.
Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project
Avoid hanging at startup when a process has a *.lock file open in the .git
directory.
The goal is to repair stale locks, not wait for all active locks to be
closed. This was causing problems for a non-git process that has its own
lock file in a subdir of .git/.
If .git/index_lock is a non-stale lock, this does let the assistant start
up regardless. Commits by the assistant will then fail, until the process
locking the index finishes. This is not a problem, because the same
behavior could already happen if the assistant is started and then another
process locks the index.
Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project
