Date: Sun, 14 Sep 2025 21:38:29 -0700 From: Chris Torek <chris.torek@gmail.com> To: bob prohaska <fbsd@www.zefox.net> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Git and buildworld running at the same time Message-ID: <CAPx1GvcehAWojmhU0BgUChpS1cwxaC1rtfoUo0Z2jMa1QNJzbw@mail.gmail.com> In-Reply-To: <aMeTCZlxh6qrcK80@www.zefox.net> References: <BCA57115-27E8-43FE-9A7E-120A28857A32@yahoo.com> <D9B77D14-C4DE-41CD-B3B6-916A8B6B0A8A@yahoo.com> <aMeTCZlxh6qrcK80@www.zefox.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On Sun, Sep 14, 2025 at 9:17 PM bob prohaska <fbsd@www.zefox.net> wrote:
> 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.
>
The problem here is that you can't know whether
a `git fetch` will launch a `git gc --auto`, and there is
no `--no-detach` option for `git fetch`. But:
[Mark Millard, I think]
> > > # 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?
>
No. The `git config` command (now preferably spelled
`git config set` for this particular purpose) writes the
desired configuration to your specified Git configuration
file (system, user-global, repository-local, worktree-local,
or specified file) , where it resides until changed.
Meanwhile `git gc --no-detach --auto` means "run the
gc command now, with flags auto and no-detach"; the
"no-detach" overrides whichever configuration file
setting would take effect without it. But as I noted above,
the problem is that "git fetch" itself runs the GC for you.
Your options are therefore one or both of these:
1. Set it in your configuration (you probably want to use
the default local config for this, or perhaps user-global
so that if it's not set locally your user-global setting gets
used).
2. All Git commands take `-c` options. These set internal
environment variables that get passed on to future internally-
executed Git commands, so you can force a "git fetch" to
run a "git gc" with the environment setting (note that the
env setting overrides all config file settings but not any
command-line-flag settings). So you could run:
git -c maintenance.autoDetach=false pull
to run both `git fetch` and `git merge` with any background
gc step run with wait-for-completion.
Note that the `-c` spelling uses the equals sign form,
which differs from the `git config set` form.
(This is all kind of a pain but is all part of the
backwards compatibility stuff... see, e.g., the
`gc.packRefs` setting, which exists for compatibility
with Git 1.5.1.1 and earlier! I doubt anyone has
needed it in 15 years now.)
If you use option 1 and `git config set --global`, you
don't have to change any of your other existing
workflow, you just have to be ready for any Git
command you run to take an hour-plus unexpectedly
(on your system).
(You could also tune some of the packing options
so that you run `gc` less frequently. This also has
its own set of tradeoffs...)
Chris
[-- Attachment #2 --]
<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Sep 14, 2025 at 9:17 PM bob prohaska <<a href="mailto:fbsd@www.zefox.net">fbsd@www.zefox.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Knowing that a git pull will be followed by some<br>
background work it isn't really a problem. I was<br>
fooled into starting buildworld before git finished,<br>
now I know enough to let it finish. However, for a<br>
script the --no-detach is a useful addition, at<br>
least when confident git will finish successfully. <br></blockquote><div><br></div><div>The problem here is that you can't know whether</div><div>a `git fetch` will launch a `git gc --auto`, and there is</div><div>no `--no-detach` option for `git fetch`. But:</div><div> </div><div>[Mark Millard, I think]</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > # git -C /usr/src/ config maintenance.autoDetach false<br>
> > # git -C /usr/src/ config gc.autoDetach false<br>
<br>
I'm a little confused here: are the two commands above equivalent<br>
in action to<br>
git -C /usr/src/ gc --no-detach --auto <br>
when used in a one-line script? <br></blockquote><div><br></div><div>No. The `git config` command (now preferably spelled</div><div>`git config set` for this particular purpose) writes the</div><div>desired configuration to your specified Git configuration</div><div>file (system, user-global, repository-local, worktree-local,</div><div>or specified file) , where it resides until changed.</div><div><br></div><div>Meanwhile `git gc --no-detach --auto` means "run the</div><div>gc command now, with flags auto and no-detach"; the</div><div>"no-detach" overrides whichever configuration file</div><div>setting would take effect without it. But as I noted above,</div><div>the problem is that "git fetch" itself runs the GC for you.</div><div><br></div><div>Your options are therefore one or both of these:</div><div><br></div><div>1. Set it in your configuration (you probably want to use</div><div>the default local config for this, or perhaps user-global</div><div>so that if it's not set locally your user-global setting gets</div><div>used).</div><div><br></div><div>2. All Git commands take `-c` options. These set internal</div><div>environment variables that get passed on to future internally-</div><div>executed Git commands, so you can force a "git fetch" to</div><div>run a "git gc" with the environment setting (note that the</div><div>env setting overrides all config file settings but not any</div><div>command-line-flag settings). So you could run:</div><div><br></div><div> git -c maintenance.autoDetach=false pull</div><div><br></div><div>to run both `git fetch` and `git merge` with any background</div><div>gc step run with wait-for-completion.</div><div><br></div><div>Note that the `-c` spelling uses the equals sign form,</div><div>which differs from the `git config set` form.</div></div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">(This is all kind of a pain but is all part of the</div><div class="gmail_quote gmail_quote_container">backwards compatibility stuff... see, e.g., the</div><div class="gmail_quote gmail_quote_container">`gc.packRefs` setting, which exists for compatibility</div><div class="gmail_quote gmail_quote_container">with Git 1.5.1.1 and earlier! I doubt anyone has</div><div class="gmail_quote gmail_quote_container">needed it in 15 years now.)</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">If you use option 1 and `git config set --global`, you</div><div class="gmail_quote gmail_quote_container">don't have to change any of your other existing</div><div class="gmail_quote gmail_quote_container">workflow, you just have to be ready for any Git</div><div class="gmail_quote gmail_quote_container">command you run to take an hour-plus unexpectedly</div><div class="gmail_quote gmail_quote_container">(on your system).</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">(You could also tune some of the packing options</div><div class="gmail_quote gmail_quote_container">so that you run `gc` less frequently. This also has</div><div class="gmail_quote gmail_quote_container">its own set of tradeoffs...)</div><div class="gmail_quote gmail_quote_container"></div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">Chris</div></div>
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPx1GvcehAWojmhU0BgUChpS1cwxaC1rtfoUo0Z2jMa1QNJzbw>