Issue #6106 new

Forced non fast forward merge of pull request? (BB-7307)

created an issue

I experimented with pull requests in my private repo. I did one commit into a feature branch, opened a pull request "feature->master" pressed "Merge". Master has not changed since feature branch start, so I expected "fast forward" merge to happen that would just append this one commit to master. I think this is default Git behavior -- do fast-forward merge when it can. Instead, Bitbucket did an extra Merge commit, having previous master tip and my branch commit as parents.

I think linear history is easier to read. It would be good to have fast forward merging by default when possible, or at least have an option to do so. To achieve this currently I have to merge this branch locally and then pushing to master, avoiding the whole "pull request" feature.

Or are pull requests intended to behave like this? If so, why?

Comments (40)

  1. Thomas Woolford

    muv If you have a fast-forward merge, you get linear history sure but then why are you even using a branch? As soon as you've merged, the record of your branch is hard to see. With a merge commit, It makes things explicit as to when the merge was made and by whom. I honestly think that this is the right thing for anyone taking Pull Requests (You're not just sitting there pulling yourself all day are you? ;)

  2. muv reporter

    Thomas Woolford no :) Thanks for the point, it makes sense.

    I thought I'd use pull requests as a tool to code-review a set of commits (branch), as opposed to reviewing individual commits. This branch can be discussed, rebased and cleaned up before integrating into master. I now see why no-ff is a good default setting for many cases, but I still see value in having a chance to do fast-forward merge sometimes. For example, if we are small team, pull requests come from project-aware team members (not outside), and there's no big point in keeping branch history (thus we can make it linear).

  3. codeoncoffee

    I would also like the opportunity to allow a FF from a pull request. The linear history is nice while preserving the code review aspect of pull requests. I'd really like to see and option to to create a FF by rebasing the source branch (assuming no merge conflicts in the rebase). This would go a long way toward cleaning up our history.

  4. Gergely Nagy

    +1 And for us, it would be great if only ff merges are accepted. We want to enforce that the pull request is properly tested before merged, and don't allow merges if ff is not possible.

  5. Wojciech Jankowski

    +1 Especially in Gitflow workflow when somebody adds a few commits directly to 'develop' branch it should be ff-ded to origin 'develop' branch. In this case linear history should be certainly preferred.

  6. James Foster

    Just so everyone knows...

    If you want to do a fast forward from a pull request, just do it locally and push the destination branch back to bitbucket. Bitbucket will recognise that the destination branch is up to date with the source branch and the pull request will be marked as "Merged".

    This should be sufficient for those who prefer fast forward merges.

  7. Michael Clawson

    +1 Our pull requests are already rebased down to one commit (except for feature branches). It becomes ridiculous to have alternating work and merge commits in our history.

    Manually is an awkward option because QA does our merges. We want to do the --ff-only merge in the Pull request.

  8. Ian Dunkerly

    I am currently on annual leave, returning on 13/04.

    Please contact or if you require a response sooner.

  9. Simon Young

    I am currently out of the office on annual leave and I will respond to your email on my return on 13 April 2015.

    For any urgent issues in my absence please contact Sophie Kemp on 0115 968 2270 or email

    Kind Regards

    Simon Young Web Development Manager

    Paul Smith Limited The Poplars Lenton Lane Nottingham NG7 2PW

  10. Anton Ukhanev

    Could someone please explain to me why without the FF merge a pull request would be useless? You can still see the comments, and the commits are the same. Looks like I'm missing something, since as far as I can tell all it does is create a concrete point in history.

  11. Greg Manning

    If you do a pull request from branch2 to branch1, now branch1 has a commit which branch2 does not have -- the branches have diverged. Not what we want.

  12. Anton Ukhanev

    No need to clean. All that needs to be done is merge back. This is the strategy we use with releases: there are master, develop and feature/myfeature branches. As code gets reviewed and approved, code is merged from feature/myfeature to develop. When it's time for release, release-1.2.3 is created, and changes necessary for it are made there. In the meantime, features are being merged into develop. On the release date, we simply merge release-1.2.3 into master, then master into develop.

    Like this, each release has a dedicated point in history of both master and develop, they contain the same commits, and the merge commits have a reference to the original feature branch.

  13. csbubbles

    Anton Ukhanev

    If not fast-forward, each merge create a new commit (empty and useless) in your Git repo history. If you have a couple of people working on the same project and they commit relatively often (and each feature requires not a lot of commit per se), then about half of commits (which are caused by non-FF merges) in your history is garbage.

    There are multiple strategies to use Git for the development process, people approach the one which works best for them, not necessarily that one you have mentioned. Also, it is kind of unrelated to the current issue. When you merge non-FF, then you get a new empty and useless commit. The more you merge, the more such commits you get. Regardless of your general process.

  14. Anton Ukhanev

    csbubbles, each commit that your team members make on a feature branch stays as a single commit. When the feature is ready, the code is reviewed and approved, then the merge will result in one single additional commit on the develop branch, e.g. one per feature. Additionally, every release will also create one additional commit on the master branch. If during integration testing you need to merge multiple times into your develop branch, then I believe you should create a separate throw-away integration branch, and merge to it until the feature is ready, especially if you are in favour of "clean" history.

    That said, I do not intend to state that this is the only way of doing it, and that other ways, including those which use fast-forward merges, are invalid. Instead, my question was "why without the FF merge a pull request would be useless?". The no-FF pull request merges add a feature which make subsequent tracking of repository "events" possible. I acknowledge that there may be a need for a no-FF merge.

  15. Greg Manning

    The reason it is useless for some people, is that some people have decided that the benefit from using the bitbucket pull request feature is not worth the drawback of having the commit created that they don't want.

  16. John Camelon

    Polluting the log does not make the feature useless IMO but it definitely makes it unpleasant. I have to weed through 40% more commits than I would without the feature working this way.

  17. Log in to comment