Introduce merge.ff configuration handling

[ethomson]

When the provided FastForwardStrategy is FastForwardStrategy.Default, honor the merge.ff configuration setting. When merge.ff=only, enable fast-forward only mode; when merge.ff=false, enable no-ff mode.

[ethomson]

This keeps libgit2sharp's "analysis" function to truly only perform the analysis of the mergability, such that it will always report "fastforwardable" when the merge is, indeed, fastforwardable, without contemplating policy decisions by the user.

Since LibGit2Sharp introduces the idea of a "default action", it is the layer that queries this configuration setting and applies it to the default.

/cc @nulltoken
/cc @jamill

[jamill]

libgit2 automatically handles the config options in other places (e.g. the handling of tagopts for fetching is one example). It seems inconsistent to have the library automatically take the user configurations into account in some places, but not in others. I was expecting lg2 to handle this, so that not every binding would have to implement the same logic.

[ethomson]

Yes, I thought that this would be a contentious issue. This was also my first thought, but I can't think of a sensible place to put this.

Do you think that git_merge_analysis should take the merge.ff setting into account? I don't, but I agree that it's cumbersome to make everybody deal with this setting themselves. But if not there, where?

[jamill]

What if there was another function (e.g. git_merge_preferred_merge_type for lack of a better name now), that calls into git_merge_analysis and takes into account the merge.ff setting?

[ethomson]

That seems reasonable to me.

[ethomson]

I wonder what @carlosmn thinks about this, when he has a moment.

[carlosmn]

This is missing "0" as a falsy value. I'd recommend using Config.Get<bool>("merge.ff") for this.

[nulltoken]

@ethomson Could you please consider @carlosmn's comment?

[carlosmn]

I think this could fit as part of git_merge_analysis(). Since we're pulling data for what git-merge understands and may do, and git_merge_analysis_t are ORable flags, we could set a bit or two to indicate the user's preferences via this setting.

Making use of this information is still something that should be up to the tool using libgit2.

[Therzok]

Shouldn't this be handled by the new API exposed in #722.

[ethomson]

Yes. I will update once your PR is merged.

[Therzok]

Perfecto!

[Therzok]

Just a minor update: In case you forgot, #722 is merged.

[ethomson]

Updated!

/cc @Therzok
/cc @nulltoken

[ethomson]

Oops; I rebased the wrong thing onto the wrong thing, let's try this again!

[nulltoken]

@ethomson Could you please update FastForwardStrategy.Default xml doc in order to clearly state that it will honor the merge.ff config value?

[ethomson]

@ethomson Could you please update FastForwardStrategy.Default xml doc in order to clearly state that it will honor the merge.ff config value?

@nulltoken Done!

[nulltoken]

Very very neat PR! 💖