Sandro Santilli
2014-10-17 11:59:36 UTC
Hello everybody,
today, after being waiting too much on a "git log --stat" command I went
asking for ideas in the #git channel, and reported the QGIS git repo url.
They cloned and reaction was like this:
12:42 < luto> strk: what is in there? an ubuntu iso? :D
12:44 < canton7> 925 megs in all
I went digging up history back to June 2011, when the code was moved
to git, and according to my blog post at that time the size was 330 Mb:
http://strk.keybit.net/blog/2011/06/07/getting-just-the-tip-of-a-remote-git-branch/
12:48 < luto> 200mb of XML
12:49 < luto> 4mb per file
12:50 < canton7> yeah, those xml files are like 60000 lines each
12:51 < canton7> strk, in conclusion, I'm not surprised --stat's being slow.
calculating which 50 lines have changed out of 60000
for a few files at a time is going to take a little
while :P
12:51 < canton7> 1.3 gigs for a whole clone
There might be nothing that can be done to reduce the size of the
repository w/out altering the history, but maybe some care should be put
into avoiding to make the growth so fast.
12:56 < luto> $ time git --no-pager log --stat > /dev/null
12:56 < luto> 167.40s user 2.13s system 100% cpu 2:49.38 total
12:56 < luto> $ time git --no-pager log > /dev/null
12:56 < luto> 0.34s user 0.02s system 99% cpu 0.357 total
12:56 < luto> on a ramfs and i7-3630QM (quad core, 2.4ghz)
12:56 < luto> that's really not something one can work with..
On my laptop it takes 4 minutes to run this:
time git --no-pager log --stat HEAD~100 > /dev/null
In the #git channel on freenode are going on with the analisys to try
at figure out if it's possible to alleviate the speed problem.
I though it was worth mentioning to the list.
--strk;
() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html
today, after being waiting too much on a "git log --stat" command I went
asking for ideas in the #git channel, and reported the QGIS git repo url.
They cloned and reaction was like this:
12:42 < luto> strk: what is in there? an ubuntu iso? :D
12:44 < canton7> 925 megs in all
I went digging up history back to June 2011, when the code was moved
to git, and according to my blog post at that time the size was 330 Mb:
http://strk.keybit.net/blog/2011/06/07/getting-just-the-tip-of-a-remote-git-branch/
12:48 < luto> 200mb of XML
12:49 < luto> 4mb per file
12:50 < canton7> yeah, those xml files are like 60000 lines each
12:51 < canton7> strk, in conclusion, I'm not surprised --stat's being slow.
calculating which 50 lines have changed out of 60000
for a few files at a time is going to take a little
while :P
12:51 < canton7> 1.3 gigs for a whole clone
There might be nothing that can be done to reduce the size of the
repository w/out altering the history, but maybe some care should be put
into avoiding to make the growth so fast.
12:56 < luto> $ time git --no-pager log --stat > /dev/null
12:56 < luto> 167.40s user 2.13s system 100% cpu 2:49.38 total
12:56 < luto> $ time git --no-pager log > /dev/null
12:56 < luto> 0.34s user 0.02s system 99% cpu 0.357 total
12:56 < luto> on a ramfs and i7-3630QM (quad core, 2.4ghz)
12:56 < luto> that's really not something one can work with..
On my laptop it takes 4 minutes to run this:
time git --no-pager log --stat HEAD~100 > /dev/null
In the #git channel on freenode are going on with the analisys to try
at figure out if it's possible to alleviate the speed problem.
I though it was worth mentioning to the list.
--strk;
() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html