BitBucket Server ignoring configured git merge drivers?

Geoffrey Elgey
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 4, 2023

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/ 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/ 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?

1 answer

1 vote
Andreas Borkenhagen February 23, 2024

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.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events