Re: Git and buildworld running at the same time

From: bob prohaska <fbsd_at_www.zefox.net>
Date: Mon, 15 Sep 2025 04:16:09 UTC
On Sun, Sep 14, 2025 at 02:50:03PM -0700, Mark Millard wrote:
> 
> >> At the moment git occupies 1.3 GB RAM, 505 MB swap and 10-15% CPU.
> 
> The above "1.3 GB RAM" seems odd for a RPi2B with
> only 1 GiByte of RAM. The ps columns are:
> 
> USER    PID   %CPU %MEM   VSZ   RSS TT  STAT STARTED        TIME COMMAND
> 
> RSS is a RAM usage figure (768984); VSZ is Virtual
> SiZe (1346480). VSZ can be bigger than RAM+SWAP for
> the process, as I understand. (Making simple
> arithmetic problematical.)
> 
> Was the "505 MB" system level swap usage, instead
> of process specific swap usage?
> 
The numbers came from top's SIZE and RES columns, 
thinking SIZE was total memory and RES was in ram. In
hindsight, I've no evidence for that interpretation.

> > If I gather correctly, it looks like at times, when it
> > will be a notable time before activity like building
> > software, something like:
> > 
> > git -C /usr/src/ gc --no-detach --auto
> > 
> > would be appropriate. The "--no-detach" avoids it
> > running in the background so you know when it is
> > running vs. when it finishes. You would want to do
> > this often enough to avoid fetch/merge --ff-only
> > or pull from doing such automatically or having
> > a lot of accumulated pending work to do.
> > 

Knowing that a git pull will be followed by some
background work it isn't really a problem. I was
fooled into starting buildworld before git finished,
now I know enough to let it finish. However, for a
script the --no-detach is a useful addition, at
least when confident git will finish successfully. 


> > There is:
> > 
> >     gc.autoDetach
> >         Make git gc --auto return immediately and run in the background if
> >         the system supports it. Default is true. This config variable acts as
> >         a fallback in case maintenance.autoDetach is not set.
> > 
> > and also:
> > 
> >     maintenance.autoDetach
> >         Many Git commands trigger automatic maintenance after they have
> >         written data into the repository. This boolean config option controls
> >         whether this automatic maintenance shall happen in the foreground or
> >         whether the maintenance process shall detach and continue to run in
> >         the background.
> > 
> >         If unset, the value of gc.autoDetach is used as a fallback. Defaults
> >         to true if both are unset, meaning that the maintenance process will
> >         detach.
> > 
> > So you can force it to not detach automatically.
> > But, then, you might have a long wait for the
> > command that added data to complete:
> > 
> > # git -C /usr/src/ config maintenance.autoDetach false
> > # git -C /usr/src/ config          gc.autoDetach false

I'm a little confused here: are the two commands above equivalent
in action to
 git -C /usr/src/ gc --no-detach --auto 
when used in a one-line script?  

Thanks for writing!

bob prohaska