# Bug Report 5 messages from 2023-06-27 to 2023-07-05. Participants: Tiago d'Almeida, Jeff King, Johannes Schindelin, Junio C Hamano. Thread: https://gitlist.dev/t/59919 ## Tiago d'Almeida, 2023-06-27 16:02 Subject: Bug Report Message-ID: URL: https://gitlist.dev/e/CAO%3DRawtAvOna1xrBNY%2BT-fo4UQe-ipC6OvFODvOSdu4wUML3Ng%40mail.gmail.com ``` Hello! I'm Tiago and sorry for any mistake because it is my first bug report to git. So after git updated, I begin to get some errors and unexpected git status output. I made a test git repo to test this, and here are the results: ˋˋˋ mkdir git_bug && cd git_bug git init -q && git maintenance register && echo "Done!" touch mkdir touch git status --short ## No commits yet on main ?? LICENSE ?? README.md ?? folder/ ?? folder_1/ git add git status ## No commits yet on main ?? LICENSE ?? README.md ?? folder/ ?? folder_1/ git commit -s -m "First commit" On branch main Initial commit Untracked files: LICENSE README.md folder/ folder_1/ nothing added to commit but untracked files present ˋˋˋ Attached to this email follow the `git bugreport` and global `config` files, and the git_bug repo. I've checked my global config file and it seems all ok, but if there is some error or contradicition, please tell me. Thanks in advance! 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) A normal git routine. - git add - git commit -s -m "Commit" What did you expect to happen? (Expected behavior) No errors and the files being added and commited. What happened instead? (Actual behavior) No files added. Error when tried to commit. What's different between what you expected and what actually happened? The error. Anything else you want to add: This just happened after updating git to version 2.41 [System Info] git version 2.41.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 6.3.8-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 15 02:15:40 UTC 2023 x86_64 compiler info: gnuc: 13.1 libc info: glibc: 2.37 $SHELL (typically, interactive shell): /usr/bin/fish [Enabled Hooks] ``` ## Jeff King, 2023-06-29 08:38 Subject: index.skipHash doesn't work with split index, was Re: Bug Report Message-ID: <20230629083859.GA585934@coredump.intra.peff.net> URL: https://gitlist.dev/e/20230629083859.GA585934%40coredump.intra.peff.net In-Reply-To: ``` On Tue, Jun 27, 2023 at 05:02:30PM +0100, Tiago d'Almeida wrote: > Attached to this email follow the `git bugreport` and global `config` > files, and the git_bug repo. Thanks for providing your config; it was very important to reproducing. The bug comes from the combination of "core.splitIndex" and "index.skipHash" (the latter is triggered in your config by "feature.manyFiles"). Here's a quick reproduction: git init repo cd repo touch file git -c core.splitIndex=true -c index.skipHash=true add file That should add "file" to the index but doesn't. Removing either the splitIndex option or the skipHash option makes it work. I didn't dig further than that. Adding the author of skipHash to the cc. -Peff ``` ## Jeff King, 2023-07-03 19:16 Subject: Re: index.skipHash doesn't work with split index, was Re: Bug Report Message-ID: <20230703191636.GA3546592@coredump.intra.peff.net> URL: https://gitlist.dev/e/20230703191636.GA3546592%40coredump.intra.peff.net In-Reply-To: ``` [re-adding list to cc, so everybody can benefit from the answer] On Mon, Jul 03, 2023 at 07:43:42PM +0100, Tiago d'Almeida wrote: > Meanwhile, just a question: > > How can I correct the corrupted git repos that are in my computer with > unstaged changes? Probably the best path forward is: 1. Disable one or both of the problematic config options: git config --global core.splitIndex false 2. Blow away the old index, and have git re-populate it from the HEAD commit: rm -f .git/index git reset Usually "git reset" would be enough here, but since we don't know what funny or possibly corrupted state the index file is in, deleting it first seems wise). Because the default for git-reset is "--mixed", this won't touch your working tree files at all. 3. You should then be able to run "git status" to see any differences between the working tree and the fresh index (including any untracked ones). And now "git add", etc, should work. -Peff ``` ## Johannes Schindelin, 2023-07-05 14:27 Subject: Re: index.skipHash doesn't work with split index, was Re: Bug Report Message-ID: <3b9165a7-e37e-f429-bbcb-1b95aa9731fc@gmx.de> URL: https://gitlist.dev/e/3b9165a7-e37e-f429-bbcb-1b95aa9731fc%40gmx.de In-Reply-To: <20230629083859.GA585934@coredump.intra.peff.net> ``` Hi, On Thu, 29 Jun 2023, Jeff King wrote: > On Tue, Jun 27, 2023 at 05:02:30PM +0100, Tiago d'Almeida wrote: > > > Attached to this email follow the `git bugreport` and global `config` > > files, and the git_bug repo. > > Thanks for providing your config; it was very important to reproducing. > The bug comes from the combination of "core.splitIndex" and > "index.skipHash" (the latter is triggered in your config by > "feature.manyFiles"). > > Here's a quick reproduction: > > git init repo > cd repo > touch file > git -c core.splitIndex=true -c index.skipHash=true add file I ran into this issue while debugging the `commit -am` issue I worked on in https://github.com/gitgitgadget/git/pull/1554. The reason is that `write_shared_index()` calls `do_write_index()` without any additional flags (see https://github.com/git/git/blob/v2.41.0/read-cache.c#L3300) and `do_write_index()` heeds the `index.skipHash` setting always (see https://github.com/git/git/blob/v2.41.0/read-cache.c#L2900). I briefly experimented with this diff, which is ugly and should not be used as is, but it seemed to fix the issue for me: -- snip -- diff --git a/read-cache.c b/read-cache.c index ee6bcf40351..92a4aa2f25a 100644 --- a/read-cache.c +++ b/read-cache.c @@ -3292,14 +3294,17 @@ static int write_shared_index(struct index_state *istate, struct tempfile **temp, unsigned flags) { struct split_index *si = istate->split_index; - int ret, was_full = !istate->sparse_index; + int ret, was_full = !istate->sparse_index, saved_skip_hash; move_cache_to_base_index(istate); convert_to_sparse(istate, 0); trace2_region_enter_printf("index", "shared/do_write_index", the_repository, "%s", get_tempfile_path(*temp)); + saved_skip_hash = si->base->repo->settings.index_skip_hash; + si->base->repo->settings.index_skip_hash = 0; ret = do_write_index(si->base, *temp, WRITE_NO_EXTENSION, flags); + si->base->repo->settings.index_skip_hash = saved_skip_hash; trace2_region_leave_printf("index", "shared/do_write_index", the_repository, "%s", get_tempfile_path(*temp)); -- snap -- The reason why this is needed is that the shared index _must_ have an identifer that the split index can use, and that's that index hash. Skipping it breaks that pattern. Probably a much better idea than above-mentioned diff would be to add a new flag as a sibling to `COMMIT_LOCK` (i.e. here: https://github.com/git/git/blob/v2.41.0/cache.h#L346-L348) and use that only in `write_shared_index()` to force the index hash to be computed and written. I won't have time to work on this, though. Ciao, Johannes > > That should add "file" to the index but doesn't. Removing either the > splitIndex option or the skipHash option makes it work. I didn't dig > further than that. > > Adding the author of skipHash to the cc. > > -Peff > ``` ## Junio C Hamano, 2023-07-05 17:30 Subject: Re: index.skipHash doesn't work with split index, was Re: Bug Report Message-ID: URL: https://gitlist.dev/e/xmqqttui1d1i.fsf%40gitster.g In-Reply-To: <3b9165a7-e37e-f429-bbcb-1b95aa9731fc@gmx.de> ``` Johannes Schindelin writes: > The reason why this is needed is that the shared index _must_ have an > identifer that the split index can use, and that's that index hash. > Skipping it breaks that pattern. A very good summary. ```