Re: Git and GCC

ese two problems (find minimal spanning forest with limited depth and traverse graph) with the additional constraint to avoid calculating weights / avoid calculating whole graph would be a good problem to present at CompSci course. Just a thought... -- Jakub Narebski Poland ShadeHawk on #git

Re: In future, to replace autotools by cmake like KDE4 did?

ike MPlayer IIRC, instead of its own handmade Makefile... -- Jakub Narebski ShadeHawk on #git

Re: In future, to replace autotools by cmake like KDE4 did?

Andreas Ericsson wrote: > Jakub Narebski wrote: > > > > Although there was some talk about whether giw should use autotools, > > or perhaps CMake, or handmade ./configure script like MPlayer IIRC, > > instead of its own handmade Makefile... > > > > To

Re: Git and GCC

like: > http://www.oberhumer.com/opensource/ucl/ As compared to LZO, the UCL algorithms achieve a better compression ratio but *decompression* is a little bit slower. See below for some rough timings. It is uncompression speed that is more important, because it is used much more often. -- Jakub Narebski ShadeHawk on #git

Re: Something is broken in repack

you have a pack .git/objects/pack/pack-foo.pack, then > "touch .git/objects/pack/pack-foo.keep" marks the pack as precious. Actually you can (and probably should) put the one line with the _reason_ pack is to be kept in the *.keep file. Hmmm... it is even documented in git-gc(1)... and git-index-pack(1) of all things. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git

Re: Something is broken in repack

rewrite is > done. But if you clone via network, pack might be network optimized if you use "smart" transport, not disk optimized, at least with current git which regenerates pack also on clone AFAIK. -- Jakub Narebski Poland ShadeHawk on #git