David Kastrup wrote:
quoted text
> 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.

quoted text
> 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.

quoted text
>   If a repository is used by multiple people...
>   

Then the first one will kick off the repack, and subsequent ones won't.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html