Thanks Peff for spotting the bug! Here's a series that fixes it. > And before the third one, introduction of a new entry point that > makes merge-recursive machinery inherit the already populated > in-core index, happens, I think the right solution is to write the > in-core index out---the write is not pointless. Yup, I agree with that. In fact there are some other places where we just call 'refresh_cache()' as a replacement for 'git update-index --refresh'. At least the other one in 'do_apply_stash()' also seems like a bug, as I assume the original intention (and behaviour) was that the index is refreshed after 'stash apply -q' finishes. I think in do_push_stash and do_create_stash we might be able to get away without the write, but I wasn't 100% sure, so I made them write the index after refreshing it as well, which is what the shell script did. The first patch is a small refactoring that makes the actual fix a bit easier, while the second patch is a cleanup that I found while there. Thomas Gummerer (3): factor out refresh_and_write_cache function merge: use refresh_and_write_cache stash: make sure to write refreshed cache builtin/am.c | 16 ++-------------- builtin/merge.c | 15 ++++----------- builtin/stash.c | 11 +++++++---- cache.h | 9 +++++++++ read-cache.c | 17 +++++++++++++++++ t/t3903-stash.sh | 16 ++++++++++++++++ 6 files changed, 55 insertions(+), 29 deletions(-) -- 2.23.0.rc2.194.ge5444969c9
