Index.RetrieveStatus On files that don't change length return unaltered

Question

I don't know if this is by design or not but I am having an issue with Index.RetrieveStatus returning "Unaltered" for files that have been changed but contain the same number of characters as before the change. I also found that commit will fail as well in these circumstances. I wrote a quick test to prove it to myself (below) is this expected behavior? If so is there anyway to change how the index determines status? I am using LibGit2Sharp 0.19.0.0 with the intention of updating my code soon to use 0.20.0.0.

string repoPath = @"E:\TestLoc";
Repository.Init(repoPath);
Repository repo = new Repository(repoPath);

string filePath = Path.Combine(repoPath, "test.txt");

// Initial File Commit
File.WriteAllText(filePath, "12345678");
repo.Index.Stage(filePath);
Commit initialCommit = repo.Commit(
                                "Initial Commit For Test",
                                new Signature("TestAuthor", "TestEmail", DateTimeOffset.Now),
                                new Signature("TestAuthor", "TestEmail", DateTimeOffset.Now));

// Second File Commit
File.WriteAllText(filePath, "ABCDEFGH");
repo.Index.Stage(filePath);
Commit secondCommit = repo.Commit(
                                "Second Commit For Test",
                                new Signature("TestAuthor", "TestEmail", DateTimeOffset.Now),
                                new Signature("TestAuthor", "TestEmail", DateTimeOffset.Now),
                                new CommitOptions
                                {
                                    AllowEmptyCommit = false
                                });

Answer 1

This is a known issue in libgit2/LibGit2Sharp. Make sure to subscribe and/or add comments to those issues in order to be notified when they move forward:

• LibGit2Sharp #688
• libgit2 #2703

If so is there anyway to change how the index determines status?

Simply put, if a file has been modified in the workdir within the same second after it's been staged and its content length has not changed, it will not be detected.

Until the issue is fixed, a (very) hackish workaround would be to make sure that two changes to a file do not occur within the same second (avoid tight loops, introduce a Thread.Sleep() call, ...). Yeah, I know... hackish :(