Prevent automatic merging for specific file upcoming release branches

Bob Hong December 20, 2017

We use the Bitbucket as a web content repository and have enabled automatic merging for future release branches.  This allows us to prepare content for articles that are targeted for publishing a few weeks out in an appropriate release branch, and have recent content automatically rolled forward.  This works great for merging the main content, but there are certain files, such as pom.xml that we never want to auto-merge. This is because our future release release branches have an explicit version number and this file always creates a merge conflict.

 

On my local machine, I was able to manually perform the merge of my current branch into a future release branch as follows: 

 

Created a .gitconfig file in the repo root with the following contents: 

[merge "ours"]
  driver = true

Created a .gitattributes file in the repo root as follows: 

pom.xml merge=ours

 

However, when I create a pull request between my current branch and a future release branch, I get the error: 

This pull request can't be merged.

You will need to resolve conflicts to be able to merge. More information.

 

This tells me the Bitbucket server is either not recognizing the .gitconfig or .gitattributes present in the repo root.

 

I don't have direct access to the Bitbucket server, so I was hoping I could accomplish the desired behavior by making repository specific config changes.

 

Any ideas?

 

Thanks, 

 

Bob

 

3 answers

0 votes
Semenov Evgeniy April 26, 2018

Hello there!

I'm sorry to intervent but I've got the very same situation on my Bitbucket Server 5.8.0, so I've decided to write to this topic instead of creating a new one.

 

Here is my problem:
My .gitattributes file has a string of

dist/**/* merge=ours

but seems that Bitbucket Server doesn't consider it when checking for if PR is ready to be merged: conflicts occur in dist/ folder all the time.

In the same time, merge of these branches in exact these states locally goes as expected (applying 'ours' strategy to all files in dist/ folder) after 

git config --global merge.ours.driver true

is applied.

 

Please help me achieving desired behavior on server side too.

Regards, Evgeniy

Bob Hong April 26, 2018

Hi Evgeniy, 

 

The workaround that Atlassian provided was to login to the Bitbucket server using the service account and run

```

git config --global merge.ours.driver true

```

This worked for us.  Hope this helps you as well.

 

-Bob

Semenov Evgeniy April 26, 2018

Thank you very much for your reply, Bob!

I've tried it too.
This workaround doesn't seem to work in my case :(

vaibahv sharma April 22, 2021

@Bob Hong   For me also it is not working,  Here is one more scenario which is same as above

let's say we have release/5.1  and master. master has version file as 5.2-12

i added version commit by CI-CD tools to release/5.1

so now my release/5.1 has commit C1 (version file 5.1-11) C 2 (version file 5.1-12)lets say version file.

Now raised a PR for 5.1 with "Automatic merging"  on.

PR merged to 5.1 but while merging Bitbucket raised a conflict PR release/5.1  --> master which also has version file, which I  don't want to merge version  file.  is there any way to skip this?

 

 

 

  

0 votes
Nate Hansberry
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
January 3, 2018

Hi Bob.

 

You are absolutely correct and I apologize for for that oversight.

 

When I create a PR from xml to master the pom.xml file is not preserved and the merge is successful:

Screen Shot 2018-01-03 at 10.19.38.png

 

I am seeing the same behavior when I merge the branch locally as well:

git merge xml

10:17:03.744722 git.c:344               trace: built-in: git 'merge' 'xml'

Updating 984b94d..24cd704

Fast-forward

10:17:03.751833 run-command.c:626       trace: run_command: 'gc' '--auto'

10:17:03.754529 git.c:344               trace: built-in: git 'gc' '--auto'

pom.xml | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

10:17:03.824365 git.c:344               trace: built-in: git 'symbolic-ref' '-q' 'HEAD'

As I am unable to replicate what you have described, please provide the following so we can investigate a bit further:

1. Your version of Bitbucket Server

2. The exact steps you are taking on the command line 

3. The exact steps you are taking in the Bitbucket Server UI

Bob Hong January 16, 2018

Hello, 

I've created a public repo and put together a readme with the exact steps used here: 

https://bitbucket.org/bobmhong/automerge/overview 

Internally, we use Bitbucket Server v5.5.0, but I see the same behavior on Bitbucket Cloud.

The way we would like this to work is that when pull request of a fix into release/1.1 is merged, the fix should cascade to any future release branches such as release/1.2 (based on semantic versioning).  Since we expect that a merge conflict will happen on the pom.xml file due to necessary updating of the version number, we want to prevent the merge conflict and just accept the existing pom.xml file as is.

Thanks,

Bob

Bob Hong January 16, 2018

I'm not sure why the link above isn't working when trying to navigate to it from within the community.  Seems okay of you remove these extra parameters that get added to the URL:

 ?_ga=2.215574687.900291563.1516116750-1415752656.1513189966

0 votes
Nate Hansberry
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
January 2, 2018

Hi Bob,

 

I did a bit of testing with my Bitbucket Server 5.5.0 instance and I was unable to replicate an issue.

 

Here are the steps I followed:

 

1. Define a merge driver by executing the following from my local machine:

git config --global merge.ours.driver true

2. Create a tets repo

3. Create a .gitattributes file with the following contents:

email.json merge=ours

pom.xml merge=ours

4. Git add and commit that file

5. While still on the master branch  create an email.json and a pom.xml file

6. Git add and commit those files

7. Create 2 branches from master; json and xml

8. Make a change to the json file on the json branch and make a change to the xml file on the xml branch

9. Git add and commit those file changes

10. Go back to the master branch and push everything to the remote repo/Bitbucket Server

 

In the UI, here is what I see:

 

The changes for each file are seen when compared to master

Screen Shot 2018-01-02 at 14.54.51.png

Screen Shot 2018-01-02 at 14.55.01.png

Screen Shot 2018-01-02 at 14.55.16.png

Screen Shot 2018-01-02 at 14.55.30.png

 

However when I attempt to create a Pull Request, I see the following for both branches:

Screen Shot 2018-01-02 at 14.51.33.pngScreen Shot 2018-01-02 at 14.52.04.png

 

Since the only changes were applied to 2 files that are preserved via the merge driver we defined, Bitbucket Server sees the branches as up to date with master.

 

Please note that no changes were made on the server, only on the client side as mentioned above.

 

I hope this information is helpful!

 

Nate Hansberry
Developer Tools Support

Bob Hong January 2, 2018

Hi Nate, 

I wouldn't expect any differences when creating a pull request from master to the xml or json branches since they already have all the commits in master.

What happens if you reverse the order and create a PR from xml to master or json to master?

 

Thanks,

Bob

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events