Introduce Repository.MergeCommits

[ethomson]

This introduces Repository.MergeCommits which wraps git_merge_commits and is suitable for taking two commits and getting the merge results as an Index. There's a handful of interesting details here:

• The conflict data previously had a pointer to the Repository. This meant that they always went to the repository's Index. I broke this and pass in the Index that they're supposed to pay attention to. This is probably the least contentious change.
• Since the resultant index needs to be freed with git_index_free, I made Index implement IDisposable so that consumers of Repository.MergeCommits can just wrap that in a using. To prevent anybody from trying to Dispose the Repository.Index, I only wired up Dispose for things that came from a merge.
• I refactored MergeOptions, CherryPickOptions and RevertOptions to share a common base class. They were getting a little copy-pastey. I also pulled out the git_merge_options-like things into their own base class so that MergeTreeOptions could also take advantage.

I suspect there's going to be something in here for everybody to hate! :) Other suggestions for how to implement these things are welcome.

[nulltoken]

Couldn't we move this to repo.ObjectDatabase?

[ethomson]

Sure. Do you like ObjectDatabase.MergeCommits?

[nulltoken]

👍

[nulltoken]

However, I'm not sure about the returned parameter type. I wonder if we should return a different type (an interface?).

How would this* index behave when being added/removed anything? Does git_index_write behave nicely?

[ethomson]

Yeah, I think so as well. Anything that hits UpdatePhysicalIndex is going to throw. I think perhaps something that wraps an index handle but is not an index might be appropriate. I think that you want to be able to:

• Get Conflicts
• Write it to a tree

...other things?

ReadOnlyIndex?

[ethomson]

@nulltoken did you have any thoughts on my question(s) about what to call this interface / concrete implementation and / or what additional things it should expose?

[nulltoken]

How about something like

MergeTreeResult ObjectDatabase.MergeTree(Commit one, Commit another, MergeTreeOptions options)

Where MergeTreeResult would expose a status (Success, Conflicted) and either a resulting Tree or a list of conflicts?

[ethomson]

I have updated this with some changes.

[nulltoken]

Neat!

Could you please update the commit message of Introduce ObjectDatabase.MergeCommits so that it doesn't refer to the Index any longer?

[nulltoken]

Assert.NotNull(MergeTreeStatus.Tree);
Assert.Equal(0, MergeTreeStatus.Conflicts.Count());

[ethomson]

Updated with your suggestions, @nulltoken

[ethomson]

Oops, wrote that test sloppily. Updated.

[nulltoken]

@ethomson Thanks for this. One final nitpick. b2b6139 commit message states

Introduce ObjectDatabase.MergeCommits

Provide an API to merge two commits and return the resultant result.
This Index may be analyzed looking for conflicts or otherwise to
determine the success of the merge.  This Index must be disposed when
the caller has finished with it.  Thus, Index now implements
IDisposable and Indexes that are not the repository index (ie, generated
by merge) are expected to be disposed.  The repository's index is
not expected to be disposed and is protected from disposal.

Could you please reword it so that it doesn't refer to the Index any longer?

[ethomson]

Yeah, I updated that sloppily. Fixed.