David Kastrup wrote:
You'll potentially get accumulating unfinished files from
aborted/killed repack processes.
Which can get cleaned up when the next repack starts. This is no
different from unfinished files accumulating from aborted/killed manual
repacks.
If communication fails, you'll get a
new repack session for every command you start.
Git handles this already:
$ git-gc
fatal: unable to create '.git/packed-refs.lock': File exists
error: failed to run pack-refs
Presumably in that case you would simply not fire up a new repack.
If a repository is used by multiple people...
Then the first one will kick off the repack, and subsequent ones won't.
And so on. The multiuser aspect makes it a bad idea to do any
janitorial tasks automatically. You don't really want every user to
start a repack at the same time.
Quite true, but that's already impossible, so not a problem.
One other thing: The heuristics for this can be such that users who are
already regularly running git-gc by hand will see no change in behavior.
Their repos will never get to a bad enough state that the automatic
git-gc is invoked. Old-timers who run git-gc might, in theory, never
even notice a change like this.
-Steve
-
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
