Makes it more clear what is going on.

Signed-off-by: Derrick Stolee <[email protected]>

When running 'git multi-pack-index repack', we are setting two
config options intended to speed up the underlying 'git pack-objects'
command:

    pack.delta=0    (default is 50)
    pack.window=0   (default is 10)

These were inserted to prevent the delta calculations from taking over
a user's processor during a background operation. When packing the
from-loose packs, this can become an expensive operation.

However, this came with a significant downside, due to my
misunderstanding of how these options work. When repacking the (already
nicely-packed) prefetch packs, these options force deltified trees
to become un-deltified. This means the resulting pack can be larger
than the given batch size.

To prevent losing these good deltas, drop these config options and
instead use pack.threads=1 to prevent multiple threads from taking
over the machine. In combination with the recent lower-priority git
processes, this should keep the background repack from disrupting
users, but will also keep our pack directory small.

In my testing, I used the Windows repository and ran the packfile
maintenance step with a batch size of "100m" instead of "2g". This
allowed me to run it with my real data, which was currently in a
state where "2g" would do nothing.

Before: 588m pack, repack took 50s
 After:  80m pack, repack took 28s*

The fact that the repack sped up is possibly related to writing
less data to disk. I would expect this to slow down in some cases.

This expansion of deltas explains why users running the packfile
maintenance step directly have a higher than expected steady-state.
We are not-optimally repacking the data.

Signed-off-by: Derrick Stolee <[email protected]>