1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues


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 (56)

  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 Stuart.Jones@UnicornTraining.com or Vikki.Price@UnicornTraining.com 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 sophie.kemp@paulsmith.co.uk.

    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. 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.

  12. Maxim Novikov

    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.

  13. Anton Ukhanev

    Maxim Novikov, 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.

  14. 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.

  15. 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.

  16. Maxim Novikov

    Martin Thwaites

    Yeah, what I do for now to work this issue around is after the pull request merge:

    git checkout master
    git pull
    git rebase HEAD^^
    git push -f

    Which works, but certainly not pretty as you have to do it manually on every merge and basically rewrite the history.

  17. Michal Brzezinski

    Maxim Novikov Sure, but as we can see here, currently it's not possible. So, until this feature is resolved is implemented, a possible workaround is to :

    1. don't click "merge" button (you can just close PR) and do merge via command line
    2. click "merge" button and then overwrite master branch history via command line

    So in both cases you have to use command line at some point and cannot handle all the stuff via UI, there is no way around it. And changing history of master branch is dangerous - what if you don't do it quick enough and between merging PR and rebasing someone commits? 1. option is just safer imho.

  18. Maxim Novikov

    Michal Brzezinski

    It is possible in Bitbucket Server (ex. Stash). So this ticket is a request to support the same in a free version.

    PS I have never had any issues with rewriting the history actually. The only thing is the usability - you need to do more work that you could have. It's kind of irrelevant whether you do it "quick" enough or not. Git will not update things twice at the same time, one of the updates (pushes) will just fail.

  19. Michal Brzezinski

    Sure, I am all for supporting fast forward merge here, don't get me wrong. I'm was really surprised when I discovered it's not here.

    About git safety: git push -f is not safe by definition. Normal git push fails - but with -f you can do whatever you like and any changes by others will be overwritten. Anyway, it's not related to this issue se let's not discuss it further, I just wanted to suggest my workaround for lacking PRs on Bitbucket.

  20. olivier_farlotti

    The question is not "should we FF merge or not ?". The question is "as a user of GIT can I choose, for my own reasons, to do FF merges ?"

    In my team we decided to adopt a workflow (with master/dev/feat branch model) :

    1. JIRA
    2. Bitbucket branch
    3. pull on local, dev, commit/push as often as possible
    4. dev done, local rebase -i (single commit), rebase develop, then push
    5. pull request (great thing)
    6. merge from PR

    Initially we want a clean history.

    We can do it with GIT only. Why shouldnt we do it with BitBucket ?

  21. Antonio Aversa

    +1 having a linear history is very important to us: we are already putting a lot of effort into rebasing, rewording, squashing and reordering commits before any pull request, with the clear intention of getting a readable and simplified history. These merge commits just pollute the history and jeopardize our efforts in this matter.

  22. Log in to comment