Hey! Woah! git conversion!!

[Steffen Nurpmeso]

Matthias Andree wrote in <4b498035-a6bf-4839-7f8f-8c77f0330d66 at gmx.de>:
 |Am 23.05.19 um 22:32 schrieb Steffen Nurpmeso:
 |> Oh, wow.  And sure, i have my clone now!
 |> --aggressive gc is heavyweight, and tags "introduce heads" which
 |> enlargens the synchronization list.  At the beginning i wondered
 |
 |Well, git gc --aggressive takes 22 s user time here, with ¼ s system
 |time, completes in shy of 3 s (AMD Ryzen 7 running Fedora 30, ample RAM,
 |SSD), and .git/objects is below 8 MB and contains the entire project
 |history, discounting conversion losses.

It is not that much here now too, i have relatively recently
stepped an entire decade of hardware development... and ran
directly into MDS and now running with four not eight due to
disabled hyperhyper dingsbums.  And it is all a lie here i guess,
with 8th generation i5, they say they can scale 400-3400 MHz, but
with HT disabled they won't run with less than about ~730.
Nonetheless great.  On CRUX-Linux 3.5, with a <2s boot time!

What really rocks me is NVME.  That beast scrubs 80 GB of data in
about 45 seconds, which is >400% of the old MacBook Air SSD!
*Unbelievable*!
What is ample RAM, by the way?

The thing is or was that an old git tooks its time but could GC my
FreeBSD repo, but then they must have changed something and then
it was plain impossible, regardless of all windowMemory settings.
(At least back then, git has introduced things several time which
took years to work properly, at least for my use cases;
interactive rebasing with --onto, for example.)
I never made it to compile an old git just for GC purposes,
however.  Plain laziness.

But i understand it, who cares for memory constraints any more,
especially if it is completely in the way of improving a code
path?  For me it was a no-go by then.

 |The server-side SVN was some 107 MB, the checkout created a .svn dir shy
 |of 8 MB, virtually no history (that's kept server-side) - that was for
 |the trunk, not all branches of the repo included, as you'd get with Git.

Hm, fat.  I do not remember SVN that well.  (I had never checked
that out..)  They once switched their DB backend, and then there
were an immense number of files, which was an absolute no-go on my
3600 rpm disk, so i turned back to CVS for a while, before going
to git (over short-time mercurial), then.

Still no time for the bogofilter and LMDB port for CRUX-Linux.
Next week.  Grrr..
I was contacted from a Hungarian working for Symas, by the way,
who complained that i did not report the LMDB bug(s), however he
got notice.  I promised i will try to reproduce the bug(s) with
current LMDB branch head, it is too late now, however.  Next week.
But the current LMDB release will be unreliable with bogofilter
without the other patch regardless and anyway.  ^_^

A nice Sunday i wish, Matthias!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)