Re: git gui blame: git-blame loops at 100% cpu

Previous thread: [RFC/PATCH] blind rebase --onto by Clemens Buchacher on Saturday, April 17, 2010 - 11:44 am. (1 message)

Next thread: [PATCH 0/5] Improve remote helper documentation by Ramkumar Ramachandra on Saturday, April 17, 2010 - 5:50 pm. (1 message)
From: Konrad Karl
Date: Saturday, April 17, 2010 - 4:13 pm

Dear list,

I have converted one of our Visual Source Safe repos to git (about 47000 commits, about 11 years of history, .git about 200 MB git gc'ed). 

Everything seems to be working fine but git gui blame some_file seems to
procedure correct output in the file viewer but the progress bar stops 
at 1271 of 2783 lines for one specific file and then the git-blame process
consumes 100% cpu. 
 
Plain git blame completes in a fraction of a second just fine.

git-1.7.0.1-1.fc13.x86_64 (Fedora 13). I have also tested git 1.7.0.5
- same behaviour. ditto for the latest msys git in Windows.

perhaps I should mention that most of the source files in the repo are
using crlf line endings.

The hang does not happen on all files but on many - progress percentage 
varying.

Konrad


-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser
--

From: Konrad Karl
Date: Sunday, April 18, 2010 - 2:52 pm

Grr, this was a false alarm. It finishes after about 4 Minutes and I
did not wait that long. git gui was using git-blame -C -C40.

gui.fastcopyblame=true seems to help to get sane runtimes.
(this can be achieved by checkin "Blame Copy Only On Changed Files"
 in git gui options dialog -kudos to charon in #git for this suggestion)

Perhaps this should be made the default?

Konrad
--

Previous thread: [RFC/PATCH] blind rebase --onto by Clemens Buchacher on Saturday, April 17, 2010 - 11:44 am. (1 message)

Next thread: [PATCH 0/5] Improve remote helper documentation by Ramkumar Ramachandra on Saturday, April 17, 2010 - 5:50 pm. (1 message)