Re: Git and buildworld running at the same time

On Sep 14, 2025, at 21:16, bob prohaska <fbsd@www.zefox.net> wrote:

> 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,

RES(ident) is RAM use. SIZE is virtual space for text,
data, and stack spaces, according to top's man page.
process (RES+SWAP) <= process SIZE generally.

1.3 GB might be SIZE on an RPi2B --but can not be RES
(or RAM) on an RPi2B.

May be things got out of place? 505 MB of RES and
1.3 GB for SIZE? (The values would be consistent.)

> 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.

--no-detach and --detach are not "git pull"
command line options but are "git pc" command
line options.

maintenance.autoDetach can control the behavior
of commands that do not have --no-detach and
--detach command line operations. If unset,
then gc.autoDetach controls such (if set).
If both are unset it is as if they had been
set to true (so: detach).

> 
>>> 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?  

maintenance.autoDetach and gc.autoDetach provide
the default. --no-detach on the "git gc" command
line overrides the default for that "git gc"
command.

Part of the question would be if you want to
have to remember to provide the --no-detach
vs. if you want it to be automatic.

But there are commands with no --no-detach
commnd line option that are still controlled
by maintenance.autoDetach / gc.autoDetach .

I'll note that there is also --detach for the
command line, which again overrides the default.

===
Mark Millard
marklmi at yahoo.com