Two conflicts instead of one for renamed file

[ydanila]

Reproduction steps

1. Checkout commit https://github.com/ydanila/test_git from https://github.com/ydanila/test_git
2. Renamed README.md to README2.md and commit (will be marked as renamed)
3. Pull changes from 'main' using this code

public void Pull(string branch)
{
	using (var repo = new Repository(this.repoPath))
	{
		Configuration config = repo.Config;
		var mergeOptions = new MergeOptions
		{
			FailOnConflict = true,
			OnCheckoutProgress = OnCheckoutProgress
		};

		PullOptions options = new PullOptions
		{
			FetchOptions = new FetchOptions { CredentialsProvider = this.GetCredentialsProvider() },
			MergeOptions = mergeOptions
		};

		var trackingBranch = repo.Branches[branch];

		Signature buildSignature = config.BuildSignature(DateTimeOffset.Now);
		var mergeResult = Commands.Pull(repo, buildSignature, options);

		if (mergeResult.Status == MergeStatus.Conflicts)
		{
			repo.Merge(trackingBranch.TrackedBranch, buildSignature);
			ConflictCollection conflicts = repo.Index.Conflicts;
			var changes = new List<ContentChanges>();
			foreach (Conflict conflict in conflicts)
			{
				//	...
                        }
		}
	}
}

Expected behavior

As mergeOptions.FindRenames == true it returns one conflict which has Ancestor==Readme.md, Ours==Readme2.md and Theirs==null (file deleted)

Actual behavior

It returns two conflicts. First: Second:

Version of LibGit2Sharp (release number or SHA1)

Latest: 4daf6189b0e20f878348b262d1846eb25bc6d7f6

Operating system(s) tested; .NET runtime tested

Windows .Net Fw 4.7.2

[ethomson]

This is a https://github.com/libgit2/libgit2 feature. This is by-design - we store both sides of a rename conflict so that you can identify what happened in a merge after the fact. (git just spits out information to stdout, which is not particularly helpful if you're trying to drive it programmatically.)

I was reminded of this the other day. I had hoped that merge-ort would address this in git, but I don't think that it did. If it didn't, then we should make our behavior opt-in or opt-out and allow you to match git's retched behavior.

[ydanila]

The problem here that merge can have more than one such conflict and they don't have common ancestor so I can't filter out and group such values together.

This should work via manually rename tracking for second conflict to find common ancestor?