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

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

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

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

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