Hi, On Tue, May 5, 2020 at 12:56 PM Alban Gruin <alban.gruin@xxxxxxxxx> wrote: > > The old scripted `git stash' used to create a second index to save > modified and untracked files, and restore untracked files, without > affecting the main index. This behaviour was carried on when it was > rewritten in C, and here, most operations performed on the second index > are done by forked commands (ie. `read-tree' instead of reset_tree(), > etc.). This works most of the time, except in some edge case with the > split-index when the split file has expired and is deleted by a forked > command: the main index may still contain a reference to the now-deleted > file, and subsequent operations on the index will fail [0]. Thanks for working on this! I agree that it would be nice to fix split index issues as it could help for sure with huge repositories. Sorry also that this patch series fell through the cracks. I am adding Son Luong Ngoc in Cc as he reported the issue that this series fixes. > The goal of this series is to modernise (a bit) builtin/stash.c, and to > fix the aforementionned edge case. > > I have to admit that I don't really know how to test this. > GIT_TEST_SPLIT_INDEX failed on me (gdb showed me that it does not enable > the split-index at all, at least in `git stash' and its forks), It should have worked when it was introduced, though maybe not for `git stash`. > and I'm > reluctant to add explicits tests on `git stash' about the split-index, > when nothing in its code explicitly does unusual things with the index > once this series is applied. If anyone wants to share opinions about > this, I would be happy to read them. I understand. I think the good way forward would be to fix GIT_TEST_SPLIT_INDEX and find a way to ensure that it keeps working in the future. Thanks, Christian.
