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@xxxxxxxxx> 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@xxxxxx> 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@xxxxxxxxx> 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 > > >
