Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Ran several "git commit" commands in parallel on separate repos.
Here's a simple test that does that.
```bash
dir-foreach-parallel () {
subdirs=("${(@f)$(find ./ -maxdepth 1 -mindepth 1 -type d)}")
for d in $subdirs
do
echo "$d"
pushd "$d" >/dev/null
$@ &
popd >/dev/null
done
}
mkdir -p /tmp/gitTest
cd /tmp/gitTest
for ((i=0;i<100;i++)) do mkdir git_$i; done
runTest() {
git init
USE_FS_MONITOR=true
echo -e "[user]\n\tname = Gopher\n\temail =
gopher@xxxxxxxxxxx\n[core]\n\tfsmonitor = $USE_FS_MONITOR\n"
>.git/config
GIT_TRACE=1 git commit --allow-empty -m `pwd` &>gitci.log
}
dir-foreach-parallel runTest
```
After running this, wait for output to subside, then run `jobs`.
On my machine, I usually see 5-10 hung "git commit" jobs.
Running `ps -efww | grep "git commit"` will show the repos they belong
to, which you can then use to
examine the corresponding gitci.log files. The last line of all the
files I examined for hung "git
commit" commands is:
> 3:39:04.020533 run-command.c:758 trace: start_command: /opt/homebrew/opt/git/libexec/git-core/git fsmonitor--daemon run --detach --ipc-threads=8
Setting `USE_FS_MONITOR=false` in the code above consistently results
in no hung "git commit" commands, which leads me to suspect the
problem has to do with the fsmonitor feature. It's also a decent,
though difficult to discover, workaround.
What did you expect to happen? (Expected behavior)
Concurrent git commands in separate repos shouldn't interfere with each other.
What happened instead? (Actual behavior)
Several "git commit" commands hung and failed to complete due to
fsmonitor not starting.
What's different between what you expected and what actually happened?
Success
Anything else you want to add:
* I tried to repro this on a linux box and failed. It seems to have
something to do with the macos
fsmonitor implementation.
* `uname -a` of linux box that succeeds: Linux <hostname>
6.8.0-1016-aws #17-Ubuntu SMP Mon Sep 2 13:48:07 UTC 2024 x86_64
x86_64 x86_64 GNU/Linux
* I'm running an ARM Apple M3 Pro chip, so maybe ARM specific?
* The only mac I have access to is a corporate one, which has a ton of
security monitoring software running on it in the background. It's
conceivable this could be interfering with fsmonitor somehow. I
unfortunately can't test this on a clean mac.
* This use case may seem contrived, but I actually lost a lot of time
because of it. I was trying
to run some unit tests in parallel which involved running "git
commit" commands. It took me
a long time to figure out why they were randomly hanging. In
addition, I've previously used the `dir-foreach-parallel git
commit...` pattern for actual development, when working on software
which requires changes across several dependent git repos.
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.46.2
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
libcurl: 8.4.0
zlib: 1.2.12
uname: Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30
PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6030 arm64
compiler info: clang: 15.0.0 (clang-1500.3.9.4)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
not run from a git repository - no hooks to show
