From: Sean Allred <allred.sean@gmail.com>
To: git <git@vger.kernel.org>
Subject: [BUG] `git add -p` seems to corrupt a sparse index
Date: Tue, 19 Dec 2023 05:20:03 -0600 [thread overview]
Message-ID: <m01qbia0q5.fsf@epic96565.epic.com> (raw)
What did you do before the bug happened? (Steps to reproduce your issue)
git init
for dir in a b c; do mkdir $dir && seq 1 20 > $dir/file; done
git add -A && git commit -m'Some content'
git sparse-checkout set --sparse-index b
seq 1 20 > b/file-2
git add -N b/file-2
git add -p b/file-2
git status
What did you expect to happen? (Expected behavior)
I expected to be dropped into the interactive-add workflow / see my
changes in git-status.
What happened instead? (Actual behavior)
git-add reports 'No changes' and git-status reports nothing at all
(empty output).
The original internal report also was able reproduce messaging like
fatal: cache entry out of order
warning: die() called many times. Recursion error or racy threaded death!
fatal: cache entry out of order
fatal: cache entry out of order
fatal: cache entry out of order
though I've not been able to reproduce that myself. It seems relevant
/ worth noting that core.fsmonitor would be set to 'true' in that
repository.
What's different between what you expected and what actually happened?
git-status appears to silently crash in the error case.
Compare the broken workflow with any of the following variants (all of
which work as expected):
- don't use `--intent-to-add`:
git init
for dir in a b c; do mkdir $dir && seq 1 20 > $dir/file; done
git add -A && git commit -m'Some content'
git sparse-checkout set --sparse-index b
seq 1 20 > b/file-2
git add b/file-2
git status
- don't use `sparse-checkout` at all:
git init
for dir in a b c; do mkdir $dir && seq 1 20 > $dir/file; done
git add -A && git commit -m'Some content'
seq 1 20 > b/file-2
git add -N b/file-2
git add -p b/file-2
git status
- don't use `--sparse-index` specifically:
git init
for dir in a b c; do mkdir $dir && seq 1 20 > $dir/file; done
git add -A && git commit -m'Some content'
git sparse-checkout set b
seq 1 20 > b/file-2
git add -N b/file-2
git add -p b/file-2
git status
Anything else you want to add:
Seems very related to the use of sparse-index.
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.43.0.windows.1
cpu: x86_64
built from commit: 4b968f3ea3b32a7bc50846bab49f3f381841d297
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19044
compiler info: gnuc: 13.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe
[Enabled Hooks]
--
Sean Allred
reply other threads:[~2023-12-19 11:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m01qbia0q5.fsf@epic96565.epic.com \
--to=allred.sean@gmail.com \
--cc=git@vger.kernel.org \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox