brew compatibility with git 2.37

[dmilith]

brew config output

HOMEBREW_VERSION: 3.5.4
ORIGIN: https://github.com/Homebrew/brew
HEAD: 88a5fac96752f17280e64f60926f58dff45990e0
Last commit: 21 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 43d4a715d56a63af23ecdf491db94032125683e0
Core tap last commit: 4 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.5gdXZIrfnK/org.xquartz:0
HOMEBREW_EDITOR: vim
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.8 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 13.1.6 build 1316
Git: 2.37.0 => /opt/homebrew/bin/git
Curl: 7.79.1 => /usr/bin/curl
macOS: 12.4-arm64
CLT: 13.4.0.0.1.1651278267
Xcode: 13.4.1
Rosetta 2: false

brew doctor output

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:
  php@7.4

Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause formulae that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  gnupg

Verification

• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.

What were you trying to do (and why)?

Seems like after brew upgrade the file: /opt/homebrew/var/homebrew/locks/update remains and until I delete it manually I get:

What happened (include all command output)?

Error: Another active Homebrew update process is already in progress.
Please wait for it to finish or terminate it to continue.

What did you expect to happen?

well, brew upgrade should remove the file after it's done?

Step-by-step reproduction instructions (by running brew commands)

# append "fsmonitor = true" in [core] of ~/.gitconfig
brew upgrade

[dmilith]

p.s. 1. I had to select that I resolved "brew doctor issues" while it's not true. But these warns are entirely irrelevant.

p.s. 2. Why do you drop support for something working? For instance, Qemu 6.2 build is completely gone, while the new version is broken.

[dmilith]

I'm not entirely sure if it's about the git version, but that's the only thing I recently changed.

[carlocab]

I can't reproduce this.

❯ brew config | rg Git
Git: 2.37.0 => /usr/local/opt/git/bin/git
❯ brew upgrade
==> Upgrading 1 outdated package:
pipgrip 0.8.2 -> 0.8.3
==> Downloading https://ghcr.io/v2/homebrew/core/pipgrip/manifests/0.8.3
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/pipgrip/blobs/sha256:2f57a65a3a4cca989bc7683fa6a20246c5132fb962ad3d0f480cfb26cb58dfd4
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:2f57a65a3a4cca989bc7683fa6a20246c5132fb962ad3d0f480cfb26cb58dfd4?
######################################################################## 100.0%
==> Upgrading pipgrip
  0.8.2 -> 0.8.3

==> Pouring pipgrip--0.8.3.monterey.bottle.tar.gz
🍺  /usr/local/Cellar/pipgrip/0.8.3: 993 files, 12.1MB
==> Running `brew cleanup pipgrip`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
Removing: /usr/local/Cellar/pipgrip/0.8.2... (952 files, 11.4MB)
Removing: /Users/carlocab/Library/Caches/Homebrew/pipgrip--0.8.2... (3.1MB)

[MikeMcQuaid]

p.s. 1. I had to select that I resolved "brew doctor issues" while it's not true. But these warns are entirely irrelevant.

Please resolve these

[ssbarnea]

We have at least one bug here because ""Homebrew update process is already in progress" is cryptic error, one that is often a false-positive (leftover lockfile). Brew does not say which is the file lock even if you run with -vvv.

IMHO, it is unreasonable to expect users to know the location of the lock file, especially as this one is different depending on the architecture.

[MikeMcQuaid]

@ssbarnea I can reopen this if you're able to fill in the issue template.

[mjgardner]

The root cause of @dmilith's issue is that he enabled core.fsmonitor=true in his global git config. This causes git fsmonitor--daemon to monitor all of his repos by default, including Homebrew's. The monitor process is what's holding the lock file. You can verify this by running:

ps -p $(lsof -t +d $(brew --prefix)/var/homebrew/locks)

Which will show something like this if git fsmonitor--daemon is holding the lock file:

  501 77962     1   0  8:06AM ??         0:00.05 /opt/homebrew/Cellar/git/2.37.1/libexec/git-core/git fsmonitor--daemon run --detach --ipc-threads=8

I worked around this by setting core.fsmonitor=false for Homebrew's repo:

git config --file $HOMEBREW_REPOSITORY/.git/config --replace-all core.fsmonitor false

Ideally Homebrew would set this git config on initial repo creation.

[carlocab]

Is there a way to stop the daemon so it releases the lock?

[mjgardner]

Is there a way to stop the daemon so it releases the lock?

This should do it:

kill $(lsof -t +d $(brew --prefix)/var/homebrew/locks)

[carlocab]

Is there a way to stop only the daemon instead of killing everything that might hold a lock (e.g. a currently running brew update or brew upgrade process)?

Note that this is something that should be runnable while doing brew upgrade, so being indiscriminate with kill is probably going to lead to a bad time.

[mjgardner]

Is there a way to stop only the daemon instead of killing everything that might hold a lock (e.g. a currently running brew update or brew upgrade process)?

pushd $HOMEBREW_REPOSITORY; git fsmonitor--daemon stop; popd

[ssbarnea]

Since I enabled that daemon brew become a PITA to use, I always endup with lock leftovers and brew error does not even mention where are these files and how you can remove them.

At least, it should just include the clean command line as a suggestion, so you can copy/paste it.

[carlocab]

Is there a way to stop only the daemon instead of killing everything that might hold a lock (e.g. a currently running brew update or brew upgrade process)?

pushd $HOMEBREW_REPOSITORY; git fsmonitor--daemon stop; popd

Thanks, @mjgardner. Can you test out this patch?

diff --git a/Library/Homebrew/cmd/update.sh b/Library/Homebrew/cmd/update.sh
index 0269d73ed..1aed9905c 100644
--- a/Library/Homebrew/cmd/update.sh
+++ b/Library/Homebrew/cmd/update.sh
@@ -556,6 +556,12 @@ EOS
     [[ -d "${DIR}/.git" ]] || continue
     cd "${DIR}" || continue
 
+    # Git's fsmonitor daemon will not release our lock unless we stop it.
+    if git fsmonitor--daemon status &>/dev/null
+    then
+      git fsmonitor--daemon stop 2>/dev/null
+    fi
+
     if ! git config --local --get remote.origin.url &>/dev/null
     then
       opoo "No remote 'origin' in ${DIR}, skipping update!"

Apply it in "$(brew --repository)".

[carlocab]

I tried to test my patch, but I can't reproduce the problem it's meant to fix. I set core.fsmonitor to true for my local Homebrew repository, checked that the daemon was running with git fsmonitor--daemon status, and then did successive brew updates.

[mjgardner]

A recent update must have removed my git config workaround from above:

$ git --no-pager config --file $HOMEBREW_REPOSITORY/.git/config \
  --get-all core.fsmonitor # should report false to override global config below
$ git --no-pager config --global --get-all core.fsmonitor 
true

I'll test @carlocab's patch tomorrow.

[mjgardner]

I realized that my workaround didn't account for taps. Here's a replacement that also stops any extant fsmonitor daemons:

for tap in '' $(brew tap)
do
  pushd $(brew --repo $tap) &&
  git fsmonitor--daemon stop
  git config --local --replace-all core.fsmonitor false
  popd
done