Re: Git and buildworld running at the same time

On Sep 15, 2025, at 19:37, Mark Millard <marklmi@yahoo.com> wrote:

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

Note: presuming that you have not done something like
"cd /usr/src/" first. (Sorry for the implicit
context assumption.)

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