Re: Git and buildworld running at the same time

On Sep 15, 2025, at 18:48, bob prohaska <fbsd@www.zefox.net> wrote:

> 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

"git gc", not "git pc". Sorry.

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

That is what you should expect.

FYI:

The global settings can be viewed via the likes of:

# git config list

The settings that apply to a specific place like
/usr/src/ can be viewed via the likes of:

# git -C /usr/src/ config list

That last likely also lists the same as the first,
unless there has been a /usr/src/ specific alternate
setting made. [ /usr/src/.git here is either the
repository content's directory tree or a worktree's
.git file identifying where to find such. ]

So you should be able to confirm that the
settings show up when you specify the
-C /usr/src/ sort of path.

I will note that typos like

# git -C /usr/ config list

will produce the global list if a valid path is found
(that does not have a .git directory/file for the
repository).

# git -C /NO_SUCH_PLACE/ config list

would instead complain about: "No such file or directory"

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


===
Mark Millard
marklmi at yahoo.com