gc.sh: detect more "is_dirty" conditions
commit2aac76a0c2425ff6717ca5e65cfdd967aefb6a70
authorKyle J. McKay <mackyle@gmail.com>
Fri, 12 Jan 2018 09:05:55 +0000 (12 01:05 -0800)
committerKyle J. McKay <mackyle@gmail.com>
Fri, 12 Jan 2018 09:05:55 +0000 (12 01:05 -0800)
tree87b9ebfb02cf07e4e2b498e6787bbe531d257f20
parentc76635a2777cc40b92fdbd7123ba6b0192dd7d46
gc.sh: detect more "is_dirty" conditions

Running a full garbage collection can be expensive.

Even when nothing needs to be done, Git will end up doing a full
reachability trace and writing out a new pack file and so forth.
None of which is free.

Girocco attempts to avoid this when unnecessary by noticing when
no changes have been made to the repository (or its parents in the
case of a fork) since the last gc and skipping gc in that case.

However, there's a fallback, "just in case," check.  Perhaps the
repository has been mucked with or somehow the checks to see whether
or not it's been modified gave the wrong answer.

The "is_dirty" function provides this check.

If it determines that a repository "is_dirty" then garbage collection
will never be skipped for that repository.

The check is very simple.  If there's more than one pack or ANY loose
objects present, the repository is considered to be "dirty".

Previously the check for packs was picky about the pack names.  It
would only notice names matching "pack-<hash>*.pack".

Expand on this to notice any "*.pack" (except for special, deliberately
excluded names).  The reason being that if a normal gc gets interrupted
at the wrong time, it could potentially leave packs that were in
the process of being renamed/removed and have names that do not
match the pattern.  Git is not particular about the name as long
as it ends in ".pack"; the check should not be either.

A repository with more than one pack (no matter how oddly named)
definitely qualifies as "dirty" and will now be noticed as such.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
jobd/gc.sh