Re: git-reflog 70 minutes at 100% cpu and counting

Nicolas Pitre [off-list ref] writes:

On Mon, 14 Dec 2009, Eric Paris wrote:

quoted

On Mon, 2009-12-14 at 16:23 -0500, Jeff King wrote:

quoted

On Mon, Dec 14, 2009 at 04:20:29PM -0500, Eric Paris wrote:

quoted

Updated to git-1.6.5.3-1 from Fedora rawhide and still git reflog ran
for >5 minutes at 100% cpu (I killed it, it didn't finish)

I'm pushing a copy of the whole repo (all 1.9G after bzip compression)
to

http://people.redhat.com/~eparis/git-tar/

Wowzers, that's big. Can you send just what's in .git?

So I zipped up just .git   1.2G.  I did a make clean and zipped up the
whole repo  1.3G.

Just started pushing the 1.3G file.

Maybe having a .git directory that large is the problem?

Shouldn't be, unless your repo is really badly packed.

What's the output of 'git count-objects -v' ?

Didn't somebody say that the trace hints an infinite loop not "slow
because of bad packing"?

On Mon, 14 Dec 2009, Junio C Hamano wrote:

Nicolas Pitre [off-list ref] writes:

quoted

On Mon, 14 Dec 2009, Eric Paris wrote:

quoted

On Mon, 2009-12-14 at 16:23 -0500, Jeff King wrote:

quoted

On Mon, Dec 14, 2009 at 04:20:29PM -0500, Eric Paris wrote:

quoted

Updated to git-1.6.5.3-1 from Fedora rawhide and still git reflog ran
for >5 minutes at 100% cpu (I killed it, it didn't finish)

I'm pushing a copy of the whole repo (all 1.9G after bzip compression)
to

http://people.redhat.com/~eparis/git-tar/

Wowzers, that's big. Can you send just what's in .git?

So I zipped up just .git   1.2G.  I did a make clean and zipped up the
whole repo  1.3G.

Just started pushing the 1.3G file.

Maybe having a .git directory that large is the problem?

Shouldn't be, unless your repo is really badly packed.

What's the output of 'git count-objects -v' ?

Didn't somebody say that the trace hints an infinite loop not "slow
because of bad packing"?

Maybe.  But I was curious about the size too, which turns out to be 
really bad packing.  Of course bad packing shouldn't affect the 
correctness of the repository.


Nicolas