You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's now two different lock strategies in builtin/gc.c, the existing
one introduced in 64a99eb ("gc: reject if another gc is running,
unless --force is given", 2013-08-08) where we write the hostname to the
gc.pid file, and then discard the lockfile depending on a heuristic of
whether or not it's the same etc., and this one.
With this as an entry point we'll entirely do away with the old one
since we don't use the "gc --auto" entry point.
All of that may or may not be desirable, but I think a description in
the docs & tests for how these lock files should interact would be
helpful. E.g. writing a different hostname in the gc lockfile and
setting the time on it with with "test-tool chmtime" will cause it to
plow ahead, but doing the same for "git maintenance" will stop it in its
tracks no matter the time or content.
The GC lock should stay here until all git gc commands run through cmd_maintenance().
However, we can add the necessary tests to document what happens
and possibly catch (and fix) some undesired behavior.
The text was updated successfully, but these errors were encountered:
Ævar notes:
The GC lock should stay here until all
git gc
commands run throughcmd_maintenance()
.However, we can add the necessary tests to document what happens
and possibly catch (and fix) some undesired behavior.
The text was updated successfully, but these errors were encountered: