BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index

BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index

[Kache Hit]

Hi. Output of git bugreport:

---

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)

Wanted to retain git tree structure when pulling latest and rebasing.
First indication of error was the `rebase -r` of the merge commit

What did you expect to happen? (Expected behavior)

successful --rebase-merges rebase of my commits on top of master

What happened instead? (Actual behavior)

```sh
❯ git rebase -r master
BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
(179457 > 1040)
zsh: abort      git rebase -r master
```

What's different between what you expected and what actually happened?

Anything else you want to add:

I'm currently "stuck" in this state, not sure how to recover or repro:

```sh
❯ git s
BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
(179457 > 1040)
error: git died of signal 6

❯ git log

❯ git d head~
error: git died of signal 6
BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
(179457 > 1040)

❯ git log # works

❯ git status
BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
(179457 > 1040)
zsh: abort      git status

❯ git commit --amend
BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
(179457 > 1040)
zsh: abort      git commit --amend

❯ git checkout head
fatal: Unable to create '/Users/XXXXX/YYYYY/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.  #
All of this was run while git bugreport was running
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

❯ rm /Users/XXXXX/YYYYY/.git/index.lock

❯ git checkout head
BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
(179457 > 1040)
zsh: abort      git checkout head

❯ git checkout head
fatal: Unable to create '/Users/XXXXX/YYYYY/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
```


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.37.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
compiler info: clang: 13.0.0 (clang-1300.0.29.30)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]
pre-commit
pre-push

Re: BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index

[Kache Hit]

A thought: the 179457 is reminiscent of something else I did just before this:

I was doing some "code archeology" and was headlessly checking out
some old SHAs in this large monorepo.
During checkout, it said it was updating 174823 files in total.

On Tue, Jul 19, 2022 at 2:36 PM Kache Hit <kache.hit@gmail.com> wrote:
>
> Hi. Output of git bugreport:
>
> ---
>
> 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)
>
> Wanted to retain git tree structure when pulling latest and rebasing.
> First indication of error was the `rebase -r` of the merge commit
>
> What did you expect to happen? (Expected behavior)
>
> successful --rebase-merges rebase of my commits on top of master
>
> What happened instead? (Actual behavior)
>
> ```sh
> ❯ git rebase -r master
> BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> (179457 > 1040)
> zsh: abort      git rebase -r master
> ```
>
> What's different between what you expected and what actually happened?
>
> Anything else you want to add:
>
> I'm currently "stuck" in this state, not sure how to recover or repro:
>
> ```sh
> ❯ git s
> BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> (179457 > 1040)
> error: git died of signal 6
>
> ❯ git log
>
> ❯ git d head~
> error: git died of signal 6
> BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> (179457 > 1040)
>
> ❯ git log # works
>
> ❯ git status
> BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> (179457 > 1040)
> zsh: abort      git status
>
> ❯ git commit --amend
> BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> (179457 > 1040)
> zsh: abort      git commit --amend
>
> ❯ git checkout head
> fatal: Unable to create '/Users/XXXXX/YYYYY/.git/index.lock': File exists.
>
> Another git process seems to be running in this repository, e.g.  #
> All of this was run while git bugreport was running
> an editor opened by 'git commit'. Please make sure all processes
> are terminated then try again. If it still fails, a git process
> may have crashed in this repository earlier:
> remove the file manually to continue.
>
> ❯ rm /Users/XXXXX/YYYYY/.git/index.lock
>
> ❯ git checkout head
> BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> (179457 > 1040)
> zsh: abort      git checkout head
>
> ❯ git checkout head
> fatal: Unable to create '/Users/XXXXX/YYYYY/.git/index.lock': File exists.
>
> Another git process seems to be running in this repository, e.g.
> an editor opened by 'git commit'. Please make sure all processes
> are terminated then try again. If it still fails, a git process
> may have crashed in this repository earlier:
> remove the file manually to continue.
> ```
>
>
> 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.37.1
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
> PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
> compiler info: clang: 13.0.0 (clang-1300.0.29.30)
> libc info: no libc information available
> $SHELL (typically, interactive shell): /bin/zsh
>
>
> [Enabled Hooks]
> pre-commit
> pre-push

Re: BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 4497 bytes --]

Hi Kache,

On Tue, 19 Jul 2022, Kache Hit wrote:

> A thought: the 179457 is reminiscent of something else I did just before this:
>
> I was doing some "code archeology" and was headlessly checking out
> some old SHAs in this large monorepo.
> During checkout, it said it was updating 174823 files in total.

Do you think it would be possible to whittle this down a bit, and maybe
attempt to come up with a reproducible example? Something like what is
described in https://stackoverflow.com/help/mcve.

If all else fails, and you _only_ manage to reproduce it in the original
repository, could you at least try to figure out a reliable way to get the
Git index into the indicated state (if I were you, I would start off by
switching to the pre-rebase revision, deleting `.git/index` and then
running `git reset --hard` and then see whether the bug can be
reproduced)?

Ciao,
Johannes

>
> On Tue, Jul 19, 2022 at 2:36 PM Kache Hit <kache.hit@gmail.com> wrote:
> >
> > Hi. Output of git bugreport:
> >
> > ---
> >
> > 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)
> >
> > Wanted to retain git tree structure when pulling latest and rebasing.
> > First indication of error was the `rebase -r` of the merge commit
> >
> > What did you expect to happen? (Expected behavior)
> >
> > successful --rebase-merges rebase of my commits on top of master
> >
> > What happened instead? (Actual behavior)
> >
> > ```sh
> > ❯ git rebase -r master
> > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > (179457 > 1040)
> > zsh: abort      git rebase -r master
> > ```
> >
> > What's different between what you expected and what actually happened?
> >
> > Anything else you want to add:
> >
> > I'm currently "stuck" in this state, not sure how to recover or repro:
> >
> > ```sh
> > ❯ git s
> > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > (179457 > 1040)
> > error: git died of signal 6
> >
> > ❯ git log
> >
> > ❯ git d head~
> > error: git died of signal 6
> > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > (179457 > 1040)
> >
> > ❯ git log # works
> >
> > ❯ git status
> > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > (179457 > 1040)
> > zsh: abort      git status
> >
> > ❯ git commit --amend
> > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > (179457 > 1040)
> > zsh: abort      git commit --amend
> >
> > ❯ git checkout head
> > fatal: Unable to create '/Users/XXXXX/YYYYY/.git/index.lock': File exists.
> >
> > Another git process seems to be running in this repository, e.g.  #
> > All of this was run while git bugreport was running
> > an editor opened by 'git commit'. Please make sure all processes
> > are terminated then try again. If it still fails, a git process
> > may have crashed in this repository earlier:
> > remove the file manually to continue.
> >
> > ❯ rm /Users/XXXXX/YYYYY/.git/index.lock
> >
> > ❯ git checkout head
> > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > (179457 > 1040)
> > zsh: abort      git checkout head
> >
> > ❯ git checkout head
> > fatal: Unable to create '/Users/XXXXX/YYYYY/.git/index.lock': File exists.
> >
> > Another git process seems to be running in this repository, e.g.
> > an editor opened by 'git commit'. Please make sure all processes
> > are terminated then try again. If it still fails, a git process
> > may have crashed in this repository earlier:
> > remove the file manually to continue.
> > ```
> >
> >
> > 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.37.1
> > cpu: x86_64
> > no commit associated with this build
> > sizeof-long: 8
> > sizeof-size_t: 8
> > shell-path: /bin/sh
> > feature: fsmonitor--daemon
> > uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
> > PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
> > compiler info: clang: 13.0.0 (clang-1300.0.29.30)
> > libc info: no libc information available
> > $SHELL (typically, interactive shell): /bin/zsh
> >
> >
> > [Enabled Hooks]
> > pre-commit
> > pre-push
>

Re: BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index

[Kache Hit]

Hi,

I've not been able to successfully repro this after managing to
recover from it by rebuilding the index:
https://stackoverflow.com/questions/73044253

I'm sorry I couldn't be more helpful.

On Fri, Jul 29, 2022 at 8:59 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Kache,
>
> On Tue, 19 Jul 2022, Kache Hit wrote:
>
> > A thought: the 179457 is reminiscent of something else I did just before this:
> >
> > I was doing some "code archeology" and was headlessly checking out
> > some old SHAs in this large monorepo.
> > During checkout, it said it was updating 174823 files in total.
>
> Do you think it would be possible to whittle this down a bit, and maybe
> attempt to come up with a reproducible example? Something like what is
> described in https://stackoverflow.com/help/mcve.
>
> If all else fails, and you _only_ manage to reproduce it in the original
> repository, could you at least try to figure out a reliable way to get the
> Git index into the indicated state (if I were you, I would start off by
> switching to the pre-rebase revision, deleting `.git/index` and then
> running `git reset --hard` and then see whether the bug can be
> reproduced)?
>
> Ciao,
> Johannes
>
> >
> > On Tue, Jul 19, 2022 at 2:36 PM Kache Hit <kache.hit@gmail.com> wrote:
> > >
> > > Hi. Output of git bugreport:
> > >
> > > ---
> > >
> > > 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)
> > >
> > > Wanted to retain git tree structure when pulling latest and rebasing.
> > > First indication of error was the `rebase -r` of the merge commit
> > >
> > > What did you expect to happen? (Expected behavior)
> > >
> > > successful --rebase-merges rebase of my commits on top of master
> > >
> > > What happened instead? (Actual behavior)
> > >
> > > ```sh
> > > ❯ git rebase -r master
> > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > (179457 > 1040)
> > > zsh: abort      git rebase -r master
> > > ```
> > >
> > > What's different between what you expected and what actually happened?
> > >
> > > Anything else you want to add:
> > >
> > > I'm currently "stuck" in this state, not sure how to recover or repro:
> > >
> > > ```sh
> > > ❯ git s
> > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > (179457 > 1040)
> > > error: git died of signal 6
> > >
> > > ❯ git log
> > >
> > > ❯ git d head~
> > > error: git died of signal 6
> > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > (179457 > 1040)
> > >
> > > ❯ git log # works
> > >
> > > ❯ git status
> > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > (179457 > 1040)
> > > zsh: abort      git status
> > >
> > > ❯ git commit --amend
> > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > (179457 > 1040)
> > > zsh: abort      git commit --amend
> > >
> > > ❯ git checkout head
> > > fatal: Unable to create '/Users/XXXXX/YYYYY/.git/index.lock': File exists.
> > >
> > > Another git process seems to be running in this repository, e.g.  #
> > > All of this was run while git bugreport was running
> > > an editor opened by 'git commit'. Please make sure all processes
> > > are terminated then try again. If it still fails, a git process
> > > may have crashed in this repository earlier:
> > > remove the file manually to continue.
> > >
> > > ❯ rm /Users/XXXXX/YYYYY/.git/index.lock
> > >
> > > ❯ git checkout head
> > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > (179457 > 1040)
> > > zsh: abort      git checkout head
> > >
> > > ❯ git checkout head
> > > fatal: Unable to create '/Users/XXXXX/YYYYY/.git/index.lock': File exists.
> > >
> > > Another git process seems to be running in this repository, e.g.
> > > an editor opened by 'git commit'. Please make sure all processes
> > > are terminated then try again. If it still fails, a git process
> > > may have crashed in this repository earlier:
> > > remove the file manually to continue.
> > > ```
> > >
> > >
> > > 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.37.1
> > > cpu: x86_64
> > > no commit associated with this build
> > > sizeof-long: 8
> > > sizeof-size_t: 8
> > > shell-path: /bin/sh
> > > feature: fsmonitor--daemon
> > > uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
> > > PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
> > > compiler info: clang: 13.0.0 (clang-1300.0.29.30)
> > > libc info: no libc information available
> > > $SHELL (typically, interactive shell): /bin/zsh
> > >
> > >
> > > [Enabled Hooks]
> > > pre-commit
> > > pre-push
> >

Re: BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index

[Kache Hit]

Just reporting that I ran into this again, this time with some info to
help repro, though the issue may be fixed already.

I managed to avoid it by turning off core.splitIndex, so I'd suspected
the setting conflicts with feature.manyFiles.
It could very also be/instead conflict with fsmonitor that I also use,
as mentioned in the similar/related thread:
https://public-inbox.org/git/xmqqbkhv6dw3.fsf@gitster.g/T/#m13a5ad383f040bb3a6be7641bd04aa20424a274c

Which references a splitindex & fsmonitor bug that's since been
addressed since 2.41:
https://github.com/git/git/commit/3704fed5eae8ca2fa20bcf6adb277ee83b012ce0

On Mon, Aug 22, 2022 at 9:53 PM Kache Hit <kache.hit@gmail.com> wrote:
>
> Hi,
>
> I've not been able to successfully repro this after managing to
> recover from it by rebuilding the index:
> https://stackoverflow.com/questions/73044253
>
> I'm sorry I couldn't be more helpful.
>
> On Fri, Jul 29, 2022 at 8:59 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > Hi Kache,
> >
> > On Tue, 19 Jul 2022, Kache Hit wrote:
> >
> > > A thought: the 179457 is reminiscent of something else I did just before this:
> > >
> > > I was doing some "code archeology" and was headlessly checking out
> > > some old SHAs in this large monorepo.
> > > During checkout, it said it was updating 174823 files in total.
> >
> > Do you think it would be possible to whittle this down a bit, and maybe
> > attempt to come up with a reproducible example? Something like what is
> > described in https://stackoverflow.com/help/mcve.
> >
> > If all else fails, and you _only_ manage to reproduce it in the original
> > repository, could you at least try to figure out a reliable way to get the
> > Git index into the indicated state (if I were you, I would start off by
> > switching to the pre-rebase revision, deleting `.git/index` and then
> > running `git reset --hard` and then see whether the bug can be
> > reproduced)?
> >
> > Ciao,
> > Johannes
> >
> > >
> > > On Tue, Jul 19, 2022 at 2:36 PM Kache Hit <kache.hit@gmail.com> wrote:
> > > >
> > > > Hi. Output of git bugreport:
> > > >
> > > > ---
> > > >
> > > > 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)
> > > >
> > > > Wanted to retain git tree structure when pulling latest and rebasing.
> > > > First indication of error was the `rebase -r` of the merge commit
> > > >
> > > > What did you expect to happen? (Expected behavior)
> > > >
> > > > successful --rebase-merges rebase of my commits on top of master
> > > >
> > > > What happened instead? (Actual behavior)
> > > >
> > > > ```sh
> > > > ❯ git rebase -r master
> > > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > > (179457 > 1040)
> > > > zsh: abort      git rebase -r master
> > > > ```
> > > >
> > > > What's different between what you expected and what actually happened?
> > > >
> > > > Anything else you want to add:
> > > >
> > > > I'm currently "stuck" in this state, not sure how to recover or repro:
> > > >
> > > > ```sh
> > > > ❯ git s
> > > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > > (179457 > 1040)
> > > > error: git died of signal 6
> > > >
> > > > ❯ git log
> > > >
> > > > ❯ git d head~
> > > > error: git died of signal 6
> > > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > > (179457 > 1040)
> > > >
> > > > ❯ git log # works
> > > >
> > > > ❯ git status
> > > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > > (179457 > 1040)
> > > > zsh: abort      git status
> > > >
> > > > ❯ git commit --amend
> > > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > > (179457 > 1040)
> > > > zsh: abort      git commit --amend
> > > >
> > > > ❯ git checkout head
> > > > fatal: Unable to create '/Users/XXXXX/YYYYY/.git/index.lock': File exists.
> > > >
> > > > Another git process seems to be running in this repository, e.g.  #
> > > > All of this was run while git bugreport was running
> > > > an editor opened by 'git commit'. Please make sure all processes
> > > > are terminated then try again. If it still fails, a git process
> > > > may have crashed in this repository earlier:
> > > > remove the file manually to continue.
> > > >
> > > > ❯ rm /Users/XXXXX/YYYYY/.git/index.lock
> > > >
> > > > ❯ git checkout head
> > > > BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
> > > > (179457 > 1040)
> > > > zsh: abort      git checkout head
> > > >
> > > > ❯ git checkout head
> > > > fatal: Unable to create '/Users/XXXXX/YYYYY/.git/index.lock': File exists.
> > > >
> > > > Another git process seems to be running in this repository, e.g.
> > > > an editor opened by 'git commit'. Please make sure all processes
> > > > are terminated then try again. If it still fails, a git process
> > > > may have crashed in this repository earlier:
> > > > remove the file manually to continue.
> > > > ```
> > > >
> > > >
> > > > 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.37.1
> > > > cpu: x86_64
> > > > no commit associated with this build
> > > > sizeof-long: 8
> > > > sizeof-size_t: 8
> > > > shell-path: /bin/sh
> > > > feature: fsmonitor--daemon
> > > > uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
> > > > PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
> > > > compiler info: clang: 13.0.0 (clang-1300.0.29.30)
> > > > libc info: no libc information available
> > > > $SHELL (typically, interactive shell): /bin/zsh
> > > >
> > > >
> > > > [Enabled Hooks]
> > > > pre-commit
> > > > pre-push
> > >

Re: BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index

[Junio C Hamano]

Fedor Bocharov <fedor.bocharov@jetbrains.com> writes:

> Anything else you want to add:
> I have this options set in the config:
> core.fsmonitor=true
> core.splitindex=true
> ...
> feature: fsmonitor--daemon
> uname: Darwin 22.5.0 Darwin Kernel Version 22.5.0: Mon Apr 24 20:52:24 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T6000 arm64

I wonder if this is similar to what the topic that includes 3704fed5
(split-index & fsmonitor: demonstrate a bug, 2023-03-26) [*] addressed.

The fix appeared in Git 2.41-rc0 and above.


[References]

* https://lore.kernel.org/git/pull.1497.v2.git.1679870743.gitgitgadget@gmail.com/

BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index

[Fedor Bocharov]

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)
1. create commit in master (default branch)
2. amend it
3. send commit to the upstream via pull request
4. after commit is merged into the upstream, execute `git pull --rebase=merges --ff --autostash`
5. run git status

What did you expect to happen? (Expected behavior)
Git will print repository status

What happened instead? (Actual behavior)
BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index (547842 > 54)
error: git died of signal 6

What's different between what you expected and what actually happened?
I don't expect git to come into broken state after executing ordinary commands.

Anything else you want to add:
I have this options set in the config:
core.fsmonitor=true
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true
core.fsmonitor=true
core.fscache=false
core.preloadindex=true
core.multipackindex=true
core.splitindex=true
core.untrackedcache=true
submodule.active=.
branch.master.remote=origin
branch.master.merge=refs/heads/master
status.showuntrackedfiles=all

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.39.1
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 22.5.0 Darwin Kernel Version 22.5.0: Mon Apr 24 20:52:24 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T6000 arm64
compiler info: clang: 14.0.0 (clang-1400.0.29.202)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]