Is there anything else needed on this PR? Please let us know if we can help.

Sorry about the delay! A couple of things, most are stylistic and minor:

1. We like to put our out-type parameters to the function up front. Eg, something more like:

   static int git_merge__lookup_file_favor(
       int *file_favor,
       git_repository *repo,
       const char *path)
   

2. Regarding function naming, those that are fully "namespaced" with double underscores (eg, git_merge__function) are meant to be internal to the entire library. (As opposed to those that are fully namespaced with single underscores, like git_merge_files, which are public API.) For a simple static helper function like this, it should not be namespaced, and something like lookup_file_favor would be more appropriate.

3. It looks like the configuration file_favor option overrides the option specified by the caller. This should be the other way around: the configuration should override the git_merge_file_favor_t in the merge options if the options did not specify a side to favor (eg, file_favor == GIT_MERGE_FILE_FAVOR_NORMAL). However, if the options did specify a side to favor, then that should override any configuration setting.

4. Fundamentally, it would be nice to support more than just this one option to the merge attribute (eg, binary, text, etc). I don't know that this necessarily needs to be done in this pull request, but I feel like it would actually affect the architecture more fundamentally. (You would likely find that the file_favor is not the appropriate way to report this data, for example.) So this might be something that you find valuable to explore, I don't know.

Thanks, @ethomson. I've updated the PR based on your comments. I actually think the right way to support different merge attributes would be to implement custom merge drivers as mentioned in #2180 so that conflicts never actually surface here, but this seemed like an easier change to support the CHANGELOG case in the short term.

I did attempt to write a test for this case, but because I added a .gitattributes file to one of the test repositories, that seemed to have break other tests. I'm not sure what the best way to proceed there.

Neat! I think that the easiest way to test this would be to create a test that writes the gitattributes file before doing the merge. (As you point out - a lot of the other tests depend on the current state of those test repositories.)

You should be able to do something as simple as:

cl_git_mkfile("merge-resolve/.gitattributes", "*.cs merge=union\n");

(Replacing the path and contents with something more appropriate.)

Thanks for the tip, @ethomson! I've updated the PR with a test.

@ethomson, would you mind taking a look? Thank you.

Somehow my test case vanished when I rebased. Working on that...

Ok, fixed. Looks like the rebase introduced a bug that prevented this functionality from working that was caught by the test.

@ethomson Friendly reminder to review this pull request :)

Hi - sorry about the delay. Thanks so much for the fine work here.

As I reviewed this, I must admit that I felt very bad that we were going to open up merge=union as an attribute but only merge=union. This seemed begging for the custom merge driver support that #2180 had requested and been so patiently waiting for.

As a result, I opened #3564 that includes this as well as merge=<custom> support for custom merge drivers.

Thanks again!

@ethomson Thanks for implementing custom merge support--even better! I suppose we can close this PR then?

Sounds good, I rolled both these commits into that PR, so I'll go ahead and close this one.

Thanks again for the fine work.