Provide the option to use "git merge --ff-only" for pull requests (BB-7307)

Issue #6106 resolved
A
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?

Official response

  • Daniel Tao staff

    good-news.jpg

    This feature is now available in Bitbucket Labs. To try it out, enable the "Fast-forward merge strategy" feature to start merging pull requests with the --ff-only option.

    Some caveats:

    1. This feature is currently in beta. This means that while we've tested it out ourselves, there still might be some bugs. If you encounter any issues or see anything weird, let us know and we'll look into it!
    2. Fast-forward merges are only available on Git repositories.
    3. This strategy uses the --ff-only option, which means that if a fast-forward isn't possible, the merge will fail. Unfortunately the error message in this case is currently less than perfect: the UI will just inform you that there were conflicts (which, to be fair, is true). We do not currently have plans to offer a "Fast-forward if possible, otherwise create a merge commit" strategy, though we may in the future.

    Oh and @Alex Ruiz, that looks pretty serious. You should probably get that checked out.

Comments (151)

  1. Thomas Woolford

    @A 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. A reporter

    @twoolie 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. Nick Baker

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

    Really after this feature. I want to configure Bitbucket to only allow fast-forward merges when merging pull requests, and fail otherwise and inform the user a rebase is required.

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

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

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

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

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

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

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

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

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

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

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

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

  21. Sean Farley

    For sure. I was just using the other ticket as a catch all for 'different merge strategies' since implementing one would mean it'd be trivial to implement the others.

  22. Victor Escutia

    +100 I'd also love to see this option though it'd be even better to see the full stack of option the Server version provides unlike the Cloud version (check this out: https://confluence.atlassian.com/bitbucketserver/pull-request-merge-strategies-844499235.html).

    Guys, I think everything is subject to opinion so arguing as to why we need it or why we don't need it is pointless, it's the whole discussion of what's better: no ff merging vs ff merging vs rebasing vs squashing all over again... Everyone has different needs, and I can even say that everyone has had at least once, the need of using all these different options, or at least that's the case when you work in large teams and on large projects. So let's stop discussing if it's wrong or not changing history, blah blah blah... that's not the point of this ticket.

    Back to the issue at hand, as someone said, the whole idea behind pull requests is to handle all the stuff via the UI and for that, we need to have all the options available Git provides in the UI, and is up to one to use them as one pleases! and those who really understand these options to really leverage from it to get a whole world of different possibilities. By the way, the paid version of the Cloud also only supports 2 options, so it's not only the case of the free version.

    So I guess what I'm saying is why the Cloud version has to support only 2 or 3 options out of the 5 pull request merge strategies the Server version is already supporting? It just doesn't add up.

  23. Maxim Novikov

    @Robin Stocker @Sean Farley

    It's been 4 years already... Any update?

    We have been evaluating BB vs. GitHub recently as we wanted to migrate to Cloud, and decided to go with GitHub mainly because it supports this feature. So we are now paying GitHub $450 a month for their Plus plan for 50 users, and BB is missing out (us, at least) because of not supporting "rebase only" workflow and SSO / SAML.

    Do you really think this feature is not a big deal? GitHub doesn't seem to think that way, and they got us as their customers (even though we use JIRA and Confluence, and would love to use the whole Atlassian stack).

    Also, I think the title of the issue is wrong now. Who cares about specific Git commands using the UI? The request was to support pull-request merges for the "rebase workflow", which is basically:

    Introduce an option to forbid non fast-forward merges and avoid creating additional merge commits
    

    How you implement it internally and which commands you would use on your backend (GitHub, for example, does it differently cherry-picking every commit instead, I think) is irrelevant for the request, and we (users) don't really care about it.

    GitHub's example:

    Screen Shot 2017-02-26 at 3.21.18 AM.png

  24. Evin Callahan

    I'd like to inquire about the status of this, can someone please provide an update?

    Here's our use case: we use tags as a way to tie a docker image, to a commit itself. So if we get an image built in branch A, I don't want to have to go recreate that same image again when it gets merged to branch B. That's what happens when the extra 'merge-commit' occurs, and there's no way of selecting a --ff-only option during merge time in bitbucket cloud. This causes us to have to rebuild the image when it just doesnt make sense to.

    I'm surprised I haven't seen this use case much in this thread, but supporting an option that git uses out of the box seems like a no brainer to me.

  25. Paul Wagland

    This functionality is close to what I want. What I would really love is the GitLab:

    Merge commit with semi-linear history

    A merge commit is created for every merge, but merging is only allowed if fast-forward merge is possible. This way you could make sure that if this merge request would build, after merging to target branch it would also build. When fast-forward merge is not possible, the user is given the option to rebase.

    Would it be possible to get this?

  26. Sean Farley

    It's something I'm working on but need to work with some designers and also some other projects I'm assigned. I'm trying to get this done soon but we'll see.

  27. Waldir Pimenta

    Just to add to Paul Wagland's comment above about a semi-linear history: this is described nicely in the post A tidy, linear Git history. The illustration used there explains the difference visually quite well, and I took the liberty to add a pure linear workflow to the diagram to demonstrate the differences between merge vs. rebase && merge --ff-only (linear) vs. rebase && merge --no-ff (semi-linear):

    merge vs. rebase-ff vs. rebase-no-ff.png

    GitLab supports this already, as Paul mentions, and it would be great if Bitbucket did as well.

  28. Andrew Howden

    There's a vote button in the top right. Please don't +1 this issue, instead, click the vote button.

    +1'ing generates emails to already cluttered inboxes. You're not exactly killing tree's by wasting paper, but you are generating countless vibrations, popups, alerts, noises and other flora and fauna that generally make our lives busier.

    Thanks for understanding <3

  29. Alec Sammon

    +1 !! I know there is much debate about if this is a good strategy or not, however we have some specific use cases that makes this essential for us.

    At the moment we are looking to move all our private repos to GitHub, unless BitBucket can give us some timeline on when this might be available.

    @Sean Farley - can you update us with some estimated timeline please?

    Thanks

  30. Dan Rumney

    I appreciate the work being done, but what's the critical challenge here? This is already available in Bitbucket Server and has been for a long time.

    The debate about whether ff merges are good or bad is irrelevant. That's an organizational decision that should be made by the team working with the repo. What's unclear is why this is not available on the Cloud version of a git instance when it's a standard git function.

  31. Vladimir Blagojevic

    It is harder and more time consuming to mark all the duplicates of this issue than implementing the feature altogether. I can not believe how many people have asked for such a simple thing, wrote all these comments...what a waste.

  32. Can Celasun

    Hundreds of people get email notifications for this issue, so please refrain from commenting if you don't have anything new to add. Everything that can be said about this issue has already been said over the past 5 years, so all we can do is wait.

  33. Maxim Novikov

    @Can Celasun What you have written as well, by the way. :)

    I personally think that it's better to write as many comments as we can, even if it's just +1. This is the only way to have at least a chance that the folks at Atlassian will eventually notice and do something about it. Also, it shows that there are other people who care and would like to get this feature supported (which is great).

    "Votes" or anything else is no help. And who doesn't want to receive updates/comments can simply click "stop watching" button at the top.

  34. Nenad Miksa

    @Maxim Demenko Novikov, I guess that Atlassian folks have stopped watching this issue or redirected their e-mail notifications to spam. Because this feature really shouldn't be difficult to implement. I guess they don't care and are OK with loosing some customers due to that (Github is still almost twice as expensive as Bitbucket premium and other competitors are practically non-existing).

  35. Waldir Pimenta

    I personally think that it's better to write as many comments as we can, even if it's just +1.

    I disagree, and I'm sure many here do as well. Have you considered that there might be a silent majority trying not to add to the noise by speaking up against the flood of +1 comments while not adding anything substantial to the discussion (which is what Can and I have now been forced to do)?

    This is the only way to have at least a chance that the folks at Atlassian will eventually notice and do something about it. "Votes" or anything else is no help.

    The evidence points quite to the contrary direction. Comments have been added for years now without influencing the outcome of the discussion. If we assume that votes have no effect, then by the same logic we should conclude that adding more comments doesn't either.

    And who doesn't want to receive updates/comments can simply click "stop watching" button at the top.

    So people are forced to either handle a constant stream of comments that don't advance the discussion, or be left in the dark regarding actual progress? I'm pretty sure every one who subscribed to the notifications for this issue wanted the actual news, not repeated comments restating the problem we all know already. Those leaving +1 after +1 are the ones misusing the notification feature, not the subscribers, so IMO there's no sense in shifting the burden to the latter, especially when this doesn't even accomplish anything with Atlassian.

    A final plea to everyone leaving +1 or similar comments: please, before pushing the "Comment" button, remember that every new post in this thread forces hundreds of people to deal with an extra message in their inboxes; and although it's a small effort individually, the cumulative effect is quite disruptive. So use this "power" with care and respect for everyone else's time.

  36. Garret Wilson

    I can see both sides. It's irritating as customer not to have essential features, and it adds insult to injury for Atlassian to ignore the votes of popular requests. (Those goobers won't even add Markdown to JIRA.) But Waldir has a good point that it leaves no way for someone to be notified of the status yet not be inundated by +1s.

    So here's another idea that might address both concerns: instead of adding +1, why not file a new issue for the same request? That way Atlassian is informed of its popularity, yet Atlassian, and not other users, is inconvenienced by these "pings" as it were. Sure, it's almost a little virtual civil disobedience, but I don't think it's unethical. Anyway, I'm just brainstorming --- maybe someone else has a better idea for getting Atlassian's attention.

  37. Henri Tremblay

    Here are my 2 cents. This feature is already available on premise. Not having it on the cloud means Atlassian is not using a cluster of the latest on premise versions to power their cloud. This is highly frightening and if I was Altassian, I would consider this to be a big big fail.

    More than that, this issue is now 5 years old. It means the on premise version and the cloud version as been diverging for that long at least. Deeply deeply frightening. Maintaining two separate versions of the same product must be costly. Which can explain why this issue has never came on top of the priorities.

    If you are a paying customer, I would suggest that you complain directly to Atlassian support. That's the best place to get attention.

  38. Daniel Tao staff

    Disclaimer: there are lots of comments on this issue, and I have not read them all yet. That said, hopefully I can provide an update that will make most of you who are requesting this feature happy.

    First, let me answer @A's question:

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

    Yes, by default, pull requests work this way. We like having merge commits for merged pull requests because they provide more context than you would have from a fast-forward merge. For example, the default commit message we use to populate a merge commit when merging a PR references the PR by its ID, which is potentially invaluable historical information. If you want to see the discussion that took place around a particular set of changes, this is a breadcrumb that you can follow back to that discussion. We also populate merge commits by default with the names of the teammates who approved the changes in a pull request. This can be super helpful; it gives you the names of additional people you can ask for more context about a change besides just the commit author.

    All that said, if you've merged any pull requests recently (like, in the past year) then you know that merge commits are not the only merge strategy available in Bitbucket Cloud. Back in 2017 we introduced the option to squash commits before merging a pull request on a Git repository. We're very open to adding fast-forward merges to the (admittedly short) list of strategies available for those teams who prefer a linear history over the benefits of merge commits outlined above.

    I'm not 100% sure when we'll be delivering this functionality but I think we can probably get it done in the next month or so.

    I would commit to coming back to this issue to share progress by a specific date, but I know our beloved Bitbucket users will let me know if too much time has passed without an update ;)

  39. Nenad Miksa

    @Daniel Tao, I am not sure if we understand each other correctly.

    What me and my team expect from this issue is for BitBucket to merge the Pull Request using the following git syntax:

    # on destination branch
    git merge origin/feature --ff-only --no-ff
    

    The --no-ff flag would ensure creation of merge commit, which you can populate with all helpful information you already provide and --ff-only flag would prevent accidentally merging pull requests from branches which are not rebased onto destination branch and thus have possibly conflicts that would be automatically resolved (hence not shown in the BitBucket UI) in a wrong way, thus making the destination branch unstable.

    Consider this scenario with two developers and two code reviewers.

    Developer1 works on feature1 and developer2 works on feature2 in parallel. Both developers are done with their features roughly at the same time and create two pull requests to master branch from their feature branches.

    Code reviewer 1 reviews the PR from developer 1 and decides to merge it. In the meantime, code reviewer 2 reviews the PR from developer 2 and decides to merge it, but he/she is not aware that just few moments ago code reviewer 1 merged the PR from developer 1 and accidentally merges the PR from developer 2, because all conflicts can be resolved automatically by git and therefore BitBucket UI does not prevent the merge. This not only results with git history that is not linear-ish, but also poses a significant problem if automatic conflict resolution breaks the build - although PR from developer 2 could be successfully built and destination branch after merging the PR from developer 1 could be successfully built, the final merge commit cannot be successfully built. This often happens to our team (compilation actually passes, but unit test and memcheck/sanitizer tests are usually affected by this situation).

    Now, if Bitbucket UI prevented the code reviewer 2 to merge PR from developer 2 because --ff-only flag would trigger merge error due to source branch not being rebased onto destination branch, then this situation wouldn't happen and code reviewer 2 could simply ask developer 2 to rebase its branch and fix potential errors that will occur after rebasing before updating his/her PR.

    I hope this gives you a clearer image and better emphasis of the problem. Having a linear history is actually the least problem here :-)

  40. Alex Ruiz

    We do this by sending the PR , waiting for approves and the merging manually and pushing to master, but this requires granting write access to the master branch and it kind of a PITA to do this everytime, and skip the urge to click the button and screw the linear commit history.

  41. Alon Diamant

    Alex Ruiz, nah, have faith.

    @Daniel Tao is the Site Lead of Bitbucket in Austin, and if he says "month or so" then I believe him.

    Daniel, as you said above, we (the beloved Bitbucket users) are now letting you know that too much time has passed without an update ;)

    FYI: this lacking functionality is seriously making our team consider moving to GitLab or GitHub. It causes our master, develop and feature branches have tons of redundant merge commits, and makes reading the git log very difficult. It is adding to our operational expenditure.

  42. Daniel Tao staff

    Thanks for keeping me honest, everyone :)

    Before I give an update, I should make an observation, which is unfortunately true of almost every issue that has received many votes (and comments!) from the community, such as this one: this request has become different things to different people. My original response was aimed at Alex, the original reporter of this issue. This is what he said:

    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.

    Here's another clue as to what this issue was originally about: I just looked it up, and the original title was "Forced non fast forward merge of pull request?"

    With that in mind, I am treating this issue as being about linear history and the option to use fast-forward merges to close pull requests. (So @Nenad Miksa, while I definitely understand the request you are making—using --ff-only to enforce a certain workflow while using --no-ff to always create a merge commit—that is a different request from this one, and we'll need a separate ticket to track it.)

    OK, now that I've said all that... the promised update.

    On the Bitbucket team we periodically have something called "focus weeks", when the devs on the team get to put their regular project work on hold and work on something else. We have one coming up shortly. My plan is to get someone on the team to do this or do it myself.

    TL;DR: Give me one more month (hopefully sooner), and we should have the ability to close a pull request with a fast-forward merge from the UI... or at the very least another update :)

  43. Nenad Miksa

    (So @Nenad Miksa, while I definitely understand the request you are making—using --ff-only to enforce a certain workflow while using --no-ff to always create a merge commit—that is a different request from this one, and we'll need a separate ticket to track it.)

    I am glad that we sorted that out. Now, will someone explain why this issue has been marked as a duplicate of this one? I wouldn't be in this thread otherwise.

  44. Alon Diamant

    @Daniel Tao Great news!

    And yes, it seems like a few misunderstood the original issue. Most (95% of the people here) are talking about using fast-forward to merge-in pull requests. It is as follows, to make thinks crystal clear:

    First:

    master branch:
    commit A, commit B, commit C <-- HEAD
    

    A new feature branch is created, being based on master:

    feature branch:
    commit A, commit B, commit C <-- HEAD
    

    Some work is done, so now feature branch contains a new commit:

    feature branch:
    commit A, commit B, commit C, commit D <-- HEAD
    

    PR is from feature branch to master branch, so the diff contains purely commit D. After the PR is merged, using fast-forward, this is the situation:

    master branch:
    commit A, commit B, commit C, commit D <-- HEAD
    
    feature branch:
    commit A, commit B, commit C, commit D <-- HEAD
    

    Now master and feature branch are the same.

    Thanks, @Daniel Tao , we will be waiting in anticipation.

  45. pullrequesteval

    Great Summary @Alon Diamant !!!!

    I hope you put me in the 95% ;)

    to complete your summary what about the use case where master contain new commit during the pull request. Let me steal your diagram^^

    First :

    master branch:
    commit A, commit B, commit C <-- HEAD
    

    A new feature branch is created, being based on master:

    feature branch:
    commit A, commit B, commit C <-- HEAD
    

    Some work is done, so now feature branch contains a new commit:

    feature branch:
    commit A, commit B, commit C, commit D <-- HEAD
    

    but some work is also done on master :

    master branch:
    commit A, commit B, commit C, commit E
    

    now with current merge you will end-up with master :

    master branch:
    commit A, commit B, commit C, commit E, commitMerge <-- HEAD
                                              |
    feature branch:                           |
    commit A, commit B, commit C, commit D----|
    

    But with --ff-only you won't have right to merge

    So currently you choose the merge option after clicking on the merge button but the warning flag you can't merge appear before you click on the merge button.

    So my point is i will be very happy with this option but it will be weird to use if i can choose the default merge option

  46. Tomer Nosrati

    Hey @Daniel Tao. "TL;DR: Give me one more month (hopefully sooner), and we should have the ability to close a pull request with a fast-forward merge from the UI... or at the very least another update :)"

    Well, it's been a month since :)

    Thank you!

  47. Maxim Novikov

    @Daniel Tao That's not really nice... Instead of supporting this thing, you switched to a 20% project for your personal fun... It doesn't sound like Atlassian staff really cares about their customers and their pain...

    By the way, a couple of companies I worked at before, at some point were considering which tool to choose for managing code repositories, and the "rebase / ff-merge" feature was one of the most significant factors for making a decision. And they all went with GitHub, because they have supported it for a long while already.

    PS I has been a BitBucket user for my personal private repositories for 5 or 6 years, actually, mainly because of the free tier, but a year ago I switched to GitHub, and merging with rebases to keep the history linear was also one of the reasons. And I have been paying to GitHub since then. So, maybe it's something for you to think about if you want to keep up with the rest of the world, and have BitBucket attractive and useful.

  48. Daniel Tao staff

    good-news.jpg

    This feature is now available in Bitbucket Labs. To try it out, enable the "Fast-forward merge strategy" feature to start merging pull requests with the --ff-only option.

    Some caveats:

    1. This feature is currently in beta. This means that while we've tested it out ourselves, there still might be some bugs. If you encounter any issues or see anything weird, let us know and we'll look into it!
    2. Fast-forward merges are only available on Git repositories.
    3. This strategy uses the --ff-only option, which means that if a fast-forward isn't possible, the merge will fail. Unfortunately the error message in this case is currently less than perfect: the UI will just inform you that there were conflicts (which, to be fair, is true). We do not currently have plans to offer a "Fast-forward if possible, otherwise create a merge commit" strategy, though we may in the future.

    Oh and @Alex Ruiz, that looks pretty serious. You should probably get that checked out.

  49. pullrequesteval

    @Daniel Tao A good start but .......... seriously that's it ???!!!!!!!!!!!!!!!

    5years !!!!!!!!!! + 1 month of dev + 1 focus weeks + 1 more month + 1 ShipIt

    and you give us a beta fetaure!!!!! we can't choose it in the default merge strategy (that also take years to dev...)!!!

    No answer about my previous comment and the yellow flag....

    The beta is a good start but that can't be mark as resolved we don't want a beta feature

  50. Jonathan Little

    @Daniel Tao Thanks for getting to this. Seems like it can be a thankless job trying to balance official priorities with small nice-to-have customer requests. As developers we should all understand the compromises necessary in such a situation :)

  51. pullrequesteval

    @Alastair Wilkes Great !!!!! 🍾

    @Jonathan Little yeah we all understand compromises. But a five years request already present in bitbucket server that do not become official priorities it's strange.....

    I started to use this feature really good start. But now come an other use case :

    When we do a pullRequest we have comments that get fixed in a other commit so we obtain a dev branch like this:

    Feature-XYZ-commit -> fixComment1 -> fixOtherComment
    

    And finally approved.

    Now you see me coming one more question and I stop spamming this thread :

    Will we see

    --squash --ff-only
    

    option coming one day ;) ?????? like the one in bitbucket server

  52. Daniel Tao staff

    @Hannes Gustafsson @Alec Sammon Apologies! The feature should be restored now.

    This was an unfortunate oversight resulting from some changes deployed yesterday that needed to be reverted. I could get into how this caused the feature to go away, but I'll spare you the details. Suffice it to say that you can use the fast forward merge strategy again.

    The good news is that in the very near future, not only will this feature be officially released (out of beta), but you will also be able to set it as the default merge strategy for your repositories.

  53. Denis Pshenov

    @Daniel Tao thanks a lot for making this! However a more useful merge strategy would be a "rebase + merge --ff-only", tracked here. Alternatively, if we could sync branches using rebase instead of merge then that would solve the same issue too, tracked here. Please take a look at those two issues and I'm sure the whole Bitbucket Cloud community will be eternally greatful to you. Cheers!

  54. Log in to comment