BitBucket Server ignoring configured git merge drivers?

[Geoffrey Elgey]

I would like to ensure that certain files are not automerged from one branch to another when a pull request is merged. 

For example, I want to ensure that any files in the config directory are not merged to other branches. If a merge request contains changes for pom.xml and config/build.properties files then the only the pom.xml file is changed on the target branch.

On the BitBucker server host I can use .gitattributes file and a git merge driver defined in git system config to preserve certain files in the target branch when merging via the command line. The merge succeeds and I can see evidence that the configured merge driver was called to leave the config/build.properties file unchanged. However this did not work when merging pull requests via BitBucker Server UI as a merge conflict was generated.

The official philosophy seems to be "any merge conflicts must be resolved in the client repository and pushed back to the remote repository" so I assume that means git configuration regarding merge drivers is ignored.

Is there some way around this, e.g. via script runner to perform cherry picking, perhaps?

[Andreas Borkenhagen]

We have the same problem and were able to fully unscramble what is happening.

What is Bitbucket doing on a pull request?

1. It initializes a completely empty temp repository

2. It adds a ".git/objects/info/alternates" containing a file system link to the original repository

3. Doing a reset mixed to the source hash of the pull request (git reset --quiet <sha1> --)

4. Doing a merge tree (git merge-tree --write-tree --allow-unrelated-histories --messages <sha1 a> <sha1 b>

The problem here is: This merge is completely happening without any contents in the workdir!

That was not a problem before Git v2.34 but in this version Git changed it's default merge strategy from "recursive" to "ort" (Ostensibly Recursive’s Twin).

The main difference for our issue is how recursive and ort are evaluating the .gitattributes. While recursive is reading .gitattributes from index ort is expecting the .gitattributes to be in the working directory.

For a "git merge" it's possible to enforce the merge strategy by either setting "-s recursive" on the command or to set an environment variable, for ort there doesn't seem to be an option to fall back.

So it's Git 2.34 that broke compatibility.