Re: Git and buildworld running at the same time

On Sun, Sep 14, 2025 at 10:01:54PM -0700, Mark Millard wrote:
> 
> May be things got out of place? 505 MB of RES and
> 1.3 GB for SIZE? (The values would be consistent.)

Yes, likely I mixed numbers and labels 8-(
 
> > 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
> > 

It's starting to sink in 8-) 
I've run the two commands above. So, in the case of a command like
git pull > pull.log  && buildworld > build.log &
can I expect buildworld won't start before git is finished? If
not then I'm really confused.....
 

> 
> 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.
>
In this case automatic --no-detach is likely better.
Buildworld on a Pi takes days, an hour here or there
matters relatively little.
 
Thanks for all your help!

bob prohaska

>