Matthieu Moy writes:
> Junio C Hamano writes:
>
>> But a "gc" does not necessarily run "repack -a" when it does not see
>> too many pack files, so it can end up scanning only the surface of
>> the history to collect the recently created loose objects into a
>> pack, and stop its traversal withou
Junio C Hamano writes:
> But a "gc" does not necessarily run "repack -a" when it does not see
> too many pack files, so it can end up scanning only the surface of
> the history to collect the recently created loose objects into a
> pack, and stop its traversal without going into existing packfile
On Sun, Dec 2, 2012 at 3:01 PM, Junio C Hamano wrote:
> Sitaram Chamarty writes:
>
>> If I could assume that a successful 'git gc' means an fsck is not
>> needed, I'd save a lot of time. Hence my question.
>
> When it does "repack -a", it at least scans the whole history so you
> would be sure t
Sitaram Chamarty writes:
> If I could assume that a successful 'git gc' means an fsck is not
> needed, I'd save a lot of time. Hence my question.
When it does "repack -a", it at least scans the whole history so you
would be sure that all the commits and trees are readable for the
purpose of enu
On Sun, Dec 2, 2012 at 9:58 AM, Shawn Pearce wrote:
> On Sat, Dec 1, 2012 at 6:31 PM, Sitaram Chamarty wrote:
>> Background: I have a situation where I have to fix up a few hundred
>> repos in terms of 'git gc' (the auto gc seems to have failed in many
>> cases; they have far more than 6700 loose
On Sat, Dec 1, 2012 at 6:31 PM, Sitaram Chamarty wrote:
> Background: I have a situation where I have to fix up a few hundred
> repos in terms of 'git gc' (the auto gc seems to have failed in many
> cases; they have far more than 6700 loose objects). I also found some
> corrupted objects in some
6 matches
Mail list logo
