Cannot git_reset_default on a deleted file

[joshaber]

1. Rename main.m to something else.
2. Stage both the old and new file name.
3. Note that git.git shows it as a rename.
4. Call git_reset_default with the old name.
5. Get an error:

code: -3, description: "Index does not contain main.m"

[ethomson]

Eek. Is there some mechanism by which git core will support this workflow, or are you suggesting that libgit2 should be able to do better? Running rename detection during git_reset seems particularly costly.

[jspahrsummers]

Is the error simply that staged deletions can't be reset?

[joshaber]

@jspahrsummers Yep, I bet that's it.

git_reset_default calls git_index_conflict_remove which fails when the file name doesn't exist in the index.

[arrbee]

Hmm, so this is kind of an interesting case. I don't think rename detection is required for this to work correctly.

The problem is that git_reset_default runs a reversed git_diff_tree_to_index to find the changes in the index using the pathspec which actually successfully finds the deleted main.m file (as an ADDED file, because the diff is reversed), but then it unconditionally runs git_index_conflict_remove on the deleted file which fails with a GIT_ENOTFOUND because the file in question has been removed from the index.

I think the correct behavior is to ignore GIT_ENOTFOUND from git_index_conflict_remove, at least if the delta has status GIT_DELTA_ADDED (and maybe for all cases).

[carlosmn]

Did this get fixed with the PR?

[ethomson]

I think #2286 fixed this, feel free to reopen if there's still a problem here!