I've rebased and updated this test (and fixed some copy-paste errors). The issue seems to come down to whether we consider the incoming path for a conflict to be the new correct one, like we do for git_index_add(), or just one possibility, like we do for git_index_add_bypath().

I'd be inclined to let each stage have their own capitalisation, but I'm not sure what that would mean for a case-sensitive filesystem. How can we have a conflict with different names there?

The test has been updated to the semantics I mentioned above, where git_index_conflict_add() does the same path copying as git_index_add(). /cc @ethomson @nulltoken

I'd be inclined to let each stage have their own capitalisation, but I'm not sure what that would mean for a case-sensitive filesystem. How can we have a conflict with different names there?

That's a good question - and you could not. However, you can git_index_conflict_add() with any three paths you want and they'll each get added... but if they're three completely different paths (or three paths differing in case on a case sensitive system) then there will be no link between them.

If you wanted to preserve some link, you could also add a record in the NAME extension... I concede that we may be able to improve things here by writing a NAME record when we think that it would be appropriate, and we can address that issue separately if we decide that we want to.