Anyway to make bitbucket do a fast forward merge when syncing a fork?

[Sean McCleary]

Hello. My team uses git and bitbucket. We have a team repository which all the other team members fork. When the master branch of their forks gets out of date, bitbucket notifies them and asks if they'd like to sync their repository.

This is cool, but when using this feature, bitbucket ALWAYS makes a new commit for this sync, even if a fast forward merge would have been possible.

This is causing us a problem, because if a team member creates a feature branch then sends a pull request to the main repo (selecing the option to pull it into a "new branch" with the same name), bitbucket gets confused when showing the diff for this pull request. The diff includes all the changes which were bring in via those snyc operations, because those syncs created new revisions.

You can repeat this by doing the following:

1) Create a new (blessed) repo with a simple text file in it.

2) Fork this repo

3) Make a change in the blessed repo and push it up to bitbucket.

4) When your fork tells you its outdated, choose the option to "sync" it with the blessed repo. You can see that this creates a new revision in git, even though a fast-forward merge would have been possible.

5) On your fork, create a feature branch, push it up to bitbucket and issue a pull request, selecing the option to create a new branch in this pull request. You can see that the diff on this pull request contains not only the changes made on this branch, but also the changes made on the blessed repo back in step 3.

Is there a way around this problem? It's kind of making the pull request feature useless for us, as it doesn't show an accurate diff.

[Contractor 3]

is this still not fixed?

[Grzegorz Ilnicki]

Probably this is very difficult for BitBucket developers to make possible the merge strategy with fast-forward. 1 June 2018 and still no progress!

[Serjux]

+1 , in end of 2017 , I' like do git merge --ff , and the option is git merge --no--ff , why you don't let us git merge with default options ?

[Phil Terry]

New user Bitbucket long time git/gitolite user, just ran into this on our first pull usage. Agree this makes the use of this pretty messy.... three years and no answer? This showed up in my search on this issue.

[aMarcus]

I don't think this has anything to do with whether or not there is a merge commit. This sounds instead like the Pull Request may be comparing the wrong two branches. Which direction and what repositories is the Pull Request going to? For example, in your blessed repo example: Is the fork creating a Pull request back to the same branch on the detination? When you sync, the system syncs the default branch only. This means, if you issue a PR back to the blessed repo from a branch based off of soome other branch, you'll be pushing two branches of data in the PR, making the shown data correct.

Perhaps you could setup a public example of this issue that we could review to demonstrate if this is the case? Otherwise, if this doesn't seem like the issue, provide the exact details (URLs to repos and PRs) to support along with screenshots and we can take a closer look.

[Sean McCleary]

Thanks Marcus. I don't believe this is due to the wrong two branches being compared.

I am issing a pull request FROM a branch on my fork INTO a new branch on the blessed. Here are the exact steps to recreate this problem:

1) Create a new (blessed) repo.

2) Make a commit to the blessed repo (a README file perhaps)

3) Fork the repo

4) Make another commit to the blessed repo

5) When bitbucket shows your fork is outdated, click the "sync" link to update it

6) Create a new branch on your fork.

7) Issue a pull request FROM that new branch of your fork INTO a new branch on your blessed. The "diff" shows the changes which you made back in step 4, and it should not.

I have left to repositories in this state in case it helps you to take a look at them.

Blessed: https://bitbucket.org/krossoverintelligence/test-repo

Fork: https://bitbucket.org/seanmccleary/test-repo

Thanks

[Sean McCleary]

Any ideas anyone?