* BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
@ 2022-07-19 21:36 Kache Hit
2022-07-19 22:20 ` Kache Hit
0 siblings, 1 reply; 7+ messages in thread
From: Kache Hit @ 2022-07-19 21:36 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
2022-07-19 21:36 BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index Kache Hit
@ 2022-07-19 22:20 ` Kache Hit
2022-07-29 15:59 ` Johannes Schindelin
0 siblings, 1 reply; 7+ messages in thread
From: Kache Hit @ 2022-07-19 22:20 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
2022-07-19 22:20 ` Kache Hit
@ 2022-07-29 15:59 ` Johannes Schindelin
2022-08-23 4:53 ` Kache Hit
0 siblings, 1 reply; 7+ messages in thread
From: Johannes Schindelin @ 2022-07-29 15:59 UTC (permalink / raw)
To: Kache Hit; +Cc: git
[-- 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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
2022-07-29 15:59 ` Johannes Schindelin
@ 2022-08-23 4:53 ` Kache Hit
2023-11-04 22:05 ` Kache Hit
0 siblings, 1 reply; 7+ messages in thread
From: Kache Hit @ 2022-08-23 4:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
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
> >
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
2022-08-23 4:53 ` Kache Hit
@ 2023-11-04 22:05 ` Kache Hit
0 siblings, 0 replies; 7+ messages in thread
From: Kache Hit @ 2023-11-04 22:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
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
> > >
^ permalink raw reply [flat|nested] 7+ messages in thread
* BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
@ 2023-06-03 18:18 Fedor Bocharov
2023-06-04 4:38 ` Junio C Hamano
0 siblings, 1 reply; 7+ messages in thread
From: Fedor Bocharov @ 2023-06-03 18:18 UTC (permalink / raw)
To: git
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]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-11-04 22:06 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-19 21:36 BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index Kache Hit
2022-07-19 22:20 ` Kache Hit
2022-07-29 15:59 ` Johannes Schindelin
2022-08-23 4:53 ` Kache Hit
2023-11-04 22:05 ` Kache Hit
2023-06-03 18:18 Fedor Bocharov
2023-06-04 4:38 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).