git [was Re: Checking out src with Mercurial]

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

As someone who uses git routinely (it's my revision control system of
choice at present)....

> If git really requires that people have at least 128M of physical
> memory to work, then I'd first ask when did NetBSD break so badly
> that the amount of physical memory becomes a limitation in this way,
> and second, why would a tool like this require that much memory in
> the first place?

git, qua git, doesn't; git can work in almost zero RAM.

HOWEVER, git is _substantially_ slower, for some operations, if the
system has to hit disk to stat() every filesystem object in the working
tree - regardless of the reason for that non-caching, though RAM
shortage is the commonest in my experience.  For tiny little ten-file
projects, this effect is basically ignorable - but, for a tree the size
of NetBSD's source, it is significant.  On large repos, my smaller-RAM
machines take substantially longer to do some git operations than
larger-RAM machines, even if the larger-RAM machine is weaker in terms
of raw CPU crunch.  The affected operations are those which run through
stat()ting everything in the working tree, such as git status or git
commit; ones which don't, such as git log, or git diff between two
commits, are not affected.  (I don't work with really big git projects;
the biggest git trees I work with are my gitifications of NetBSD source
trees.)

There are some operations, such as git pull when pulling a lot of stuff
from a large repo on a beefy machine, that do demand significant
quantities of RAM.  There have been a few times I've had to add swap to
a machine that I normally run without swap in order to get a relatively
big git operation to complete.  Only a few, though, and I normally run
smaller machines than most - though possibly not than you. :)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B