Recently, staging and unstaging functionality has been implemented (#33). Staging works as intended where if a user selects a file for staging, nodegit will stage it on that action, and the staging area is updated. However, with unstaging (moving the files back to the unstaged area), the files are instead removed from the index and become untracked (and nodegit stages the deletion of the file). This is not what is intended for the unstaging of files. It should perform a "git reset HEAD {file}" or similar action to just move the file back into the working directory and remove from the staging area.
From looking at nodegit there is APIs for resetting files, which one has been used here. But contrary to the naming of the APIs (Reset.default, Reset.reset etc) which should do a "reset" like operation, they appear to do more of a "git rm --cached" operation on the files. I could be wrong
Steps to reproduce
Clone/open a repo with files commited to it.
Make a change to a file, which will made it appear in the unstaged area of VisualGit
Move the file into the staged area (to stage the file)
Move the file back into the unstaged area
This will perform the incorrect behaviour and remove the file from the repository (stage the deletion of the file).
Recently, staging and unstaging functionality has been implemented (#33). Staging works as intended where if a user selects a file for staging, nodegit will stage it on that action, and the staging area is updated. However, with unstaging (moving the files back to the unstaged area), the files are instead removed from the index and become untracked (and nodegit stages the deletion of the file). This is not what is intended for the unstaging of files. It should perform a "git reset HEAD {file}" or similar action to just move the file back into the working directory and remove from the staging area.
From looking at nodegit there is APIs for resetting files, which one has been used here. But contrary to the naming of the APIs (Reset.default, Reset.reset etc) which should do a "reset" like operation, they appear to do more of a "git rm --cached" operation on the files. I could be wrong
Steps to reproduce
This will perform the incorrect behaviour and remove the file from the repository (stage the deletion of the file).
@softeng-701 issue size small?