Re: Git and buildworld running at the same time

bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Sun, 14 Sep 2025 16:37:03 UTC :
> 
> On Sun, Sep 14, 2025 at 09:25:33AM -0700, bob prohaska wrote:
> > 
> > Top does not show any flags applied to git, and a
> > ps -aux | grep git
> > reports only the "grep git" process, nothing else.
> 
> This claim now seems wrong. A repeat of ps -aux reports:
> 
> root@www:/usr/src # ps -aux | grep git
> root 9398 8.9 80.5 1346480 768984 - R 09:07 8:34.59 /usr/local/libexec/git-core/git pack-objects --local --delta-base-of
> root 9396 0.0 0.1 9132 860 - Is 09:07 0:00.01 /usr/local/libexec/git-core/git gc --auto --no-quiet
> root 9397 0.0 0.1 9100 868 - I 09:07 0:00.05 /usr/local/libexec/git-core/git repack -d -l -A --unpack-unreachable
> root 9499 0.0 0.2 4800 1688 1 S+ 09:29 0:00.02 grep git
> [lines are wrapped]
> 
> So, git definitely returns a shell prompt before it's finished working.
> At the moment git occupies 1.3 GB RAM, 505 MB swap and 10-15% CPU.

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.

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



===
Mark Millard
marklmi at yahoo.com