Out of curiosity, is there a (maybe optional) behavior of the underlying git_reset() API in libgit2 that you would like to see that would make this case require less code in libgit2sharp?

Out of curiosity, is there a (maybe optional) behavior of the underlying git_reset() API in libgit2 that you would like to see that would make this case require less code in libgit2sharp?

Yes. I'd like this very much. However, I'd prefer to have #257 fixed first with plain C# and decide what would be the nice options we'd like to see dealt with (Current implementation blindly assumes --ignore-unmatch) and make all of this covered with tests.

Then, if that's ok with you, I'll try to port it in libgit2.

@nulltoken - I looked at making Index.Unstage act more strictly, but decided against it - On second thought I am not sure how useful it is to only verify the file is part of the index. With your changes, we already verify an absolute path is part of the repository.

As it is, this PR is updated to include your changes (but is still tolerent to files not part of the index).

If you think that the strict option is still useful, I can add it back

Thoughts?

If you think that the strict option is still useful, I can add it back

@jamill Hmm.. While working on #270, I just (re)discovered that trying to Index.Remove() a NonExistent/Removed file was not allowed. We have to make this coherent considering all of the operations.

Is it ok to stage/unstage/remove or even move a file which doesn't exist?

I would lean toward letting the user decide about whether the operation is lenient (ie. silently ignores unmatched pathspecs).

Below a proposal for an exhaustive ruleset regarding this. Please review it carefully as I may have had made mistakes:

Staging deals with moving the state of a file from the Working Directory toward the Index

Unstaging deals with moving the state of a file from the Head toward the Index. If the Head is orphaned (ie. the current Head "contains" no commit), then the file will be considered as "non existing is the Head"

Removing deals with clearing an entry from the Index and, optionally, from the Working Directory as well

Note: I haven't dealt with Move which is slightly more complicated. I'd rather make sure the behavior Remove is settled first.

/cc @dahlbyk, @yishaigalatzer

Question: What is the expectation when an end user goes through the following process

1. Have a file in the index (previously commited)
2. Make changes and save (lets call it it file state 1)
3. Stage
4. Make more changes and save (call it file state 2)
5. Commit

I'm expecting that file state 2 is the one captured in the repository, from reading the table above i'm not 100% clear that is the case.

It seems clear to me.

@yishaigalatzer A Commit is made of the content of the Index. Staging is the process which updates the Index from the working directory. In other words, if nothing is staged, there's nothing to commit.

Considering your scenario, below are the state of the "three trees of git" after each of the step has been performed

1. v0 of the file exists in the working directory. v0 of the file exists in the Index. v0 of the file exists in the Head
2. v1 of the file exists in the working directory. v0 of the file exists in the Index. v0 of the file exists in the Head
3. v1 of the file exists in the working directory. v1 of the file exists in the Index. v0 of the file exists in the Head
4. v2 of the file exists in the working directory. v1 of the file exists in the Index. v0 of the file exists in the Head
5. v2 of the file exists in the working directory. v1 of the file exists in the Index. v1 of the file exists in the Head

I'm expecting that file state 2 is the one captured in the repository, from reading the table above i'm not 100% clear that is the case.

If only file state 1 has been staged, only file state 1 will be committed.

@nulltoken

We have to make this coherent considering all of the operations.

Yes - I missed the behavior of the other operations, I completly agree. How would you feel about handling the API consistency in a seperate issue - I can open one and bring over your table. I would like to tackle unstaging adds on an empty repository first as there is not currently another workaround here (and, the fix is available now).

/cc @dahlbyk, @yishaigalatzer , @ethomson

I would like to tackle unstaging adds on an empty repository first as there is not currently another workaround here (and, the fix is available now).

Sounds reasonable 😉 It's now merged.

How would you feel about handling the API consistency in a separate issue - I can open one and bring over your table.

👍