git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Kache Hit <kache.hit@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: BUG: fsmonitor.c:21: fsmonitor_dirty has more entries than the index
Date: Fri, 29 Jul 2022 17:59:54 +0200 (CEST)	[thread overview]
Message-ID: <orr5573q-7148-84ro-9rpq-nr7411s894r9@tzk.qr> (raw)
In-Reply-To: <CAC7ZvyYGSa-sH1LZ8Lo=NRXbvJsujgFYGPOQR5ZwGHJHZgoDzA@mail.gmail.com>

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

  reply	other threads:[~2022-07-29 16:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2022-08-23  4:53     ` Kache Hit
2023-11-04 22:05       ` Kache Hit
  -- strict thread matches above, loose matches on Subject: below --
2023-06-03 18:18 Fedor Bocharov
2023-06-04  4:38 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=orr5573q-7148-84ro-9rpq-nr7411s894r9@tzk.qr \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=kache.hit@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).