git sparse checkout - can't abort merge

Question

Using git 2.25.1 Used git sparse-checkout init/set to setup sparsecheckout.

Now I'm in situation that i need to abort merge.

Tried:

git merge --abort 

Entry 'QStreams_xxx/infra/QPrism/Qpvc/gradle_pvc/gradle_pvc.iml' not uptodate. Cannot update sparse checkout. fatal: Could not reset index file to revision 'HEAD'

Tried:

git reset --hard

Same error message.

Tried to disable sparse-checkout

git sparse-checkout disable

Error:

error: cannot disable sparse-checkout: You have unstaged changes. error: additionally, your index contains uncommitted changes.

In there any way out of this ?

Thanks Boaz

Answer 1

The merge should be more robust with Git 2.34 (Q4 2021): various mergy operations have been prepared to work efficiently with the sparse index.

This is especially true with the new (and default) merge strategy ORT ("Ostensibly Recursive's Twin", which will be the default one with Git 2.34, Q4 2021).

See commit 516680b, commit 5d9c934, commit c0b9930, commit 6957636, commit a338063, commit ad90da7 (08 Sep 2021) by Derrick Stolee (derrickstolee).
^{(Merged by Junio C Hamano -- gitster -- in commit a16dd13, 20 Sep 2021)}

merge: make sparse-aware with ORT

^{Signed-off-by: Derrick Stolee
Reviewed-by: Elijah Newren}

Allow 'git merge'^(man) to operate without expanding a sparse index, at least not immediately.
The index still will be expanded in a few cases:

1. If the merge strategy is 'recursive', then we enable command_requires_full_index at the start of the merge_recursive() method. We expect sparse-index users to also have the 'ort' strategy enabled.

2. With the 'ort' strategy, if the merge results in a conflicted file, then we expand the index before updating the working tree. The loop that iterates over the worktree replaces index entries and tracks 'original_cache_nr' which can become completely wrong if the index expands in the middle of the operation. This safety valve is important before that loop starts. A later change will focus this to only expand if we indeed have a conflict outside of the sparse-checkout cone.

3. Other merge strategies are executed as a git merge-X subcommand, and those strategies are currently protected with the 'command_requires_full_index' guard.

Some test updates are required, including a mistaken 'git checkout -b'^(man) that did not specify the base branch, causing merges to be fast-forward merges.

Answer 2

Not sure if it is the best flow, but a least it lets me some way out ...

git read-tree --restore HEAD
#now usual cleanup
git restore .
git clean -xdf