KeyNotFoundException when trying to iterate through QueryBy result set.

I’m trying to get all commits that a particular file is associated with. This is the code that I’m running:

IEnumerable<LogEntry> fileHistory = repo.Commits.QueryBy(fileRelativePath);
foreach (LogEntry version in fileHistory){
 // do something...
}

The foreach throws a KeyNotFoundException. Any idea on how to overcome this?

I’m using: LibGit2Sharp.0.23.1

[ki0ki0]

I faced the same issue. It is not necessary to change library source code to avoid this issue. It’s possible to provide custom CommitFilter with Topological sorting. FullHistory adds each parent of current commit to the map and expects to find each commit on the map. But some commits may appear in the timeline before their children and this leads to KeyNotFoundException. Maybe it’s better to allow Topological sorting only? The patch @japf suggested breaks tracking of renamed files.

[nickdurcholz]

Specifying Topological sorting does not seem to fix the issue. If anyone wants to take a crack at this, here are a couple of files that reproduce the issue using the latest version on nuget (0.25.2). git-repo.zip Program.cs.txt

Edit: After a closer look, this does not appear to be the same issue, but it is related. My issue is stemming from the fact that I am iterating commits for a specific path from multiple branch starting points. Given the following history for a single file:

* f1e67d1297e470163d3fc9260d895a716076e21f another update for change.sql
| * 3efe5e7c6747323f1b45f5107531c305255decc3 (branch) branch update for change.sql
|/
* b76f581f9dbdd1eed37da13934b4e5155a9cafa7 update change.sql
* f87bd482b7fea6320795f45eff578fe948260f04 initial commit

Iterating repository.Commits.QueryBy("change.sql", new CommitFilter { IncludeReachableFrom = repository.Branches }) will always throw a key not found exception. git log --all --graph --pretty=oneline change.sql prints the above graph, so it does seem like a bug.

Edit 2: I’ve opened a new issue #1599 for my problem since it doesn’t seem like the same issue and the topological sorting workaround doesn’t work in this case.