@rbarnes I can only agree partly with that. I'm looking for a means to ensure that any source branch being merged via PR is up-to-date with the the target branch, before it can be merged. This is to ensure that we don't introduce bugs / test failures / etc due to the merge / rebase,

The only way to do this currently is via the "--squash --ff-only" strategy:

If the source branch is out of date with the target branch, reject the merge request. Otherwise, combine all commits into one new non-merge commit on the target branch.

With the "--rebase --ff-only" strategy it will simply rebase your branch (as expected) during the PR merge, leaving up the possibility to have a broken build on the target branch afterwards.

If we had a "source branch is up-to-date with target branch" merge check instead, we could disable the PR merge until the source branch is rebased (e.g. via the new Rebase button in the PR dropdown menu)

tknerr, Bitbucket already had an --ff-only merge strategy for some time. Now it also has one that will do the rebase for you. No need for merge checks, per se, in either case.

That is an awesome addition to BB server @bturner!

Does it also include a merge check which prevents PR merges unless the branch is rebased on top of the latest state of the base branch?

That is an awesome addition to BB server @bturner!

Does this also include a PR merge check which prevents PR Merges unless the branch is rebased on top of the latest state of the base branch?

One final suggestion: For any organization that has a rebase-heavy workflow and plans to make extensive use of rebase functionality on the server, I'd strongly encourage to upgrading Git on the server to at least 2.6.0.

git-am, which is used to apply patches as part of processing a rebase, was written from being a shell script to being a C built-in, and 2.6.0 was the first version to include the change. Using git-am as a built in makes it substantially faster than the script-based command. For example, we tested a rebase which rewrote 10,000 commits, as part of developing this feature, and Git 2.2.3 took between 5 and 6 minutes to complete the rebase where Git 2.13.6 was able to finish in about one minute. For teams running Bitbucket Server on Windows, the performance difference between the shell script git-am and the C version will be even more significant, due to the higher overhead of launching new processes on Windows.

To be clear: The minimum supported Git version for Bitbucket Server 5.x remains 2.2.0, and all of the new rebase functionality will work back to that version. It'll be faster on newer versions, though.

Best regards,
Bryan Turner
Atlassian Bitbucket

joseph3 I just want to further clarify that this applies only to Bitbucket Server. Bitbucket Cloud (bitbucket.org) is a separate product, with a separate roadmap, and it still does not offer rebase support. (I'll add that Bitbucket Server doesn't have repository size limits; that's a Cloud-only restriction.)

Bitbucket Cloud's issue tracker has several rebase-related issues. I'd encourage you to vote for the ones that meet your needs, or raise a new issue if there's not a good fit already. This BSERV project is not monitored by the Cloud team.

Best regards,
Bryan Turner
Atlassian Bitbucket

Awesome!

After puzzling over this one for a long time, I've finally found an approach that keeps the performance for rebase operations much closer to our "normal" merge performance. Rebases are still slower, but in general they're pretty close.

With the performance aspect finally resolved, I'm pleased to note that Bitbucket Server 5.5 introduces support for several rebase workflows:

• Two new merge strategies
  • "Rebase and fast-forward" rebases the incoming commits from the tip of the target branch and then updates the target branch to reference the newly-rewritten commits, for linear history
  • "Rebase and merge" rebases the incoming commits from the tip of the target branch and then performs a --no-ff merge, producing a "railroad tracks"-style history
    
• A "Rebase" action in the pull request action drop-down (see BSERV-8252) to rebase a pull request's source branch from the target branch at any time, on the server
• A "Rebase" action for ref sync, to rebase changes on a fork's branch from upstream changes made to its version of the same branch
  

For organizations that want to ensure rebase workflows are not used in any repository, a system administrator can add feature.git.rebase.workflows=false to bitbucket.properties to fully disable rebase functionality in all repositories. When the feature is disabled, it cannot be overridden.

Repository administrators can enable the new "Rebase and fast-forward" and/or "Rebase and merge" strategies based on what works best for their project. Both strategies are disabled by default on all repositories; git merge --no-ff remains the default unless explicitly configured otherwise. The "Rebase" actions for pull requests and ref sync are always available, unless the entire rebase feature is disabled.

Adding support for git rebase also includes a new GitRebaseHookRequest which can be used by PreRepositoryHook and PostRepositoryHook to inspect a rebase and, in the case of a PreRepositoryHook, to reject it if desired. Branch permissions are applied to all rebase operations as normal, so if a branch has a rule to reject rewriting history, rebasing will not be allowed.

There are more things we plan to polish going forward, but I hope this MVP set of functionality will be useful. If you have any questions or suggestions, please raise issues!

Best regards,
Bryan Turner
Atlassian Bitbucket

BTW: gitlab enterprise edition supports automatic rebases of pull requests for both on-premise installs, and also their cloud hosted instances on https://githost.io

The lack of core support for this feature was the primary reason I just migrated a customer to gitlab instead of to Bitbucket, though the 1G soft repo limit in Bitbucket cloud was also an issue.

Without this, users have basically two options:

1. Accept unnecessary merge commits in their history
2. Use a significantly slower workflow if a fast-forward merge won't work.

It's extremely disappointing that rebase merges are not supported. If scaling this on Bitbucket.com isn't viable, at least consider it for self-hosted stash instances and allow companies to either turn it off or throw more hardware at the problem if necessary.

HUGE THANKS! You have done my day!

Sorry to spam everyone, I want to adjust the screenshots, which requires a new comment.

eddy.petrisor

What I mean: In order to make git-history stright, I want Bitbucket to rebase PR (before actual merging) onto the branch where it should be merged. Bitbucket must not do that if such rebase requires 3-way merge or conflict resolution. After successfull rebase, it should merged PR with `-ff` option. In other words, instead of forcing developers to rebase-and-push, Bitbucket can do that automatically by itself in major cases.

rbarnes

If I choose not to drop approvals on push, I will loose reviewing real changes (not caused by clean rebase). So, I want approvals to be saved when just rebase-and-push is done. And I want approvals to be dropped if there are some real changes to code.

If automatic rebase will be done at Bitbucket side, we know that it will not actually change code during rebase, and so we may save approval status safely.

Yes, I understand, that even clean rebase may break code. But the same is true for doing such rebase by hands. These bugs should be checked by tests, not by eyes.

socketpair193946238, the clearing of approvals is done by an add-on and is not default behaviour. Unfortunately it is at odds with the desire to do client-side rebasing without gaining reapproval. If your team values rebasing over the unapprove behaviour, they have the option of turning it off.

Why not to automate rebasing just before merging ?

For the reasons outlined above, it is a hard problem to solve while avoiding the possibility of performance problems on a busy instance. If we can find a way, we will do it.

socketpair193946238: I am unsure what you mean, do you mean why Bitbucket Server should not do the rebasing? Maybe because the developer did not test that exact code?

`rebase` and `push -f` will clear approvals. Why not to automate rebasing just before merging ?

Bryan.Turner, as I said before, I know the feature is there since we already use it. I see other understand other things by rebase workflow, while for us having to rebase locally and be able to git push -f is reasonable enough.

In our organization the merge strategy is a per project policy and the administration of the project settings is almost always done by team members via the UI (and probably almost nobody uses REST), hence why in my initial report (--BSERV-7134-- - Stash should expose the plugin.stash-scm-git.pullrequest.merge.strategy* setting in the UI*) I asked explicitly the project setting to be exposed in the UI. The issue was closed, although the UI does not expose the setting.

It might be that with an addition of this specific setting in the UI to resolve a large part of the complains, since this type of workflow matches the popular git flow workflow.

I glanced a little at the links in the description, and in all the ones that are still alive (at least 2 are dead for me), the push to server from the workstation is assumed, while the squash is mentioned just as an option, so this makes me think the conclusion above has some strong ground.

dlightle1057490454, nick482254985,

The ability to setup other merge modes is available in Bitbucket Server 4.9. If what you're looking for is a way to prevent merge commits by either using --ff to avoid unnecessary merges, while still creating them when they are necessary, or by preventing them entirely using --ff-only or --squash, that functionality is already available. It was implemented in BSERV-3093, which added per-repository-level UI and REST settings, and global and per-project level REST settings, for functionality built to support BSERV-2810 and BSERV-2857. Those settings have been available via our properties files for some time now, but changing them required manual edits and restarting the server to pick them up. The new settings can be changed via UI (at the repository level) or via REST (globally, per-project or per-repository) without restarting.

Best regards,
Bryan Turner
Atlassian Bitbucket

eddy.petrisor,

Using git merge --ff is already supported, and has been for a while. The final piece, allowing the strategy to be selectable via the UI and REST, shipped in Bitbucket Server 4.9. It's configurable globally and per project via REST, and per repository via UI and REST. For repositories where multiple merge strategies are enabled by an administrator, a dropdown was added to the "Merge" dialog allowing the merging user to select the strategy to use.

The ability to enable --ff (and any other flags which are used by git merge) has been present since Stash 2.x, with UI selection added in Bitbucket Server 4.9. So yes, if that's your definition of a "rebase workflow", then it's already shipped.

However, that's not our definition of a "rebase workflow", and reading over the comments for this issue suggests it's not the definition held by many who are requesting this feature. This feature is about git rebase, which remains unsupported. And, unfortunately, the underlying realities for git rebase simply haven't changed: Using git rebase requires a pristine working copy, which means we need a full checkout before we can call it. git merge, regardless of which options are specified, doesn't require a pristine working copy, which means we can setup the work tree much, much faster. For instances that use pull requests heavily, the additional load (especially I/O load) is likely to significantly impact their scalability.

There's definite interest in offering this functionality. In fact, there have been very recent (last few weeks) conversations about it. We monitor it, and we spar internally over possible ways we could offer it. Thus far, though, because of the pristine working copy requirement, we have not found an approach which has acceptable performance and scalability characteristics.

Best regards,
Bryan Turner
Atlassian Bitbucket

I really am having a hard time understanding why this feature (merge --ff strategy) takes so much to implement since:

1) The Bitbucket Server per project settings can be changed by the admin and it works (we use this since before Atlassian Bitbucket Server/Stash v4.5.2)

2) It appears it has never failed to work properly from pull requests

3) It makes more sense to expose it first at project level (instead of repository or pull request level) since it is most likely the same merge strategy is expected to be used in all repositories in a project

I am suspecting there is either a grave misunderstanding of the request, a lack of attention diverted to this request or some lack of transparency from Atlassian regarding some problems encountered and use cases to be supported for this request (and the other numerous "duplicate" requests).

Can somebody from Atlassian enlighten us what is the problem since the story seems very clear? Are there corner cases that blocking this? Is there some common use case that is having issues?

Opened 3 years 11 months and 20 days ago. Just close the issue and mark as won't fix. I'm taking my votes & notifications elsewhere.

@Nick Mai, in the short term, try JIRA Hooks for Stash - https://marketplace.atlassian.com/plugins/com.lb.software.stash.jira.connector.lb-software-stash-jira-connector/server/overview

It has a toggle in the Push Check hook for enforcing no merge commits in certain branches.

The merge check hook can also check that the branch has been rebased recently from it's source.

The pull request merge commits have turned our git history into a mess. We use a dev pipeline with 3 main branches that all flow through to master, plus feature and hotfix branches. Sometimes when we have a backlog of changes it becomes really tiresome to figure out which changes are where (and the git history graph becomes a useless spaghetti mess haha). Rebase PRs would help a lot with this!

I would really like to see something similar to what GitLab now has that requires a "fast forwardable" commit (git merge --ff-only) but will still create the merge commit (git merge --no-ff) because this will maintain a simplified history and ensures commits are brought current before being merged. In addition, it helps with following a branching workflow like gitflow by separating feature branches and ensuring they are identifiable based on the merge commit.

If you can combine that with a few other related features, such as a rebase button and allowing commit message overriding, this would greatly improve our usability of Bitbucket!

One even better step, too, would be to allow conflict resolution and/or interactive rebasing within the site (that would solve the squash workflow as well).

Good points david.harper1. There are indeed some existing suggestions to improve conflict resolution instructions. The main one is BSERV-7561 and it links to a couple of variations. My most recent thinking on this is to trim the instructions down so as to be less opinionated and rather link to documentation for those who need it, with various options and considerations (merge strategies, branch permissions etc) laid out.

I'll be in touch regarding your workflow separately, it sounds like your branching model has some interesting traits that I'd like to better understand.

Thanks for the comment Roger. The second statement I feel it does force that workflow because when a merge conflict occurs it prompts users to follow a series of steps to resolve that conflict, and those steps add a merge commit onto the feature branch that brings in changes from the parent branch.

This has caused us a few issues before when we have added an integration branch in-between our develop and feature branches in gitflow and a number of unrelated commits from develop end up on a feature branch when we rebase the integration branch. The pull request screen gets very confused, to the point where we don't trust Bitbucket anymore, end up destroying the branch and creating a new pull request.

I fear this is may be another ticket however, the ability to toggle the instructions that Bitbucket provides from merging to rebasing. Happy to talk through our workflow via other channels if you need it.

david.harper1, I think these two directions need to be considered differently, something this suggestion hasn't been entirely clear on.

Rebase when merging back into the base branch via a Pull Request

This is not something we intentionally force as a workflow, but it is true that this is how it works in-product, and this feature suggestion is about changing that. We are not opposed to catering for such a workflow, but I want to set expectations... unlike squash and other merge strategies already available via config and subject to future improvement per BSERV-2810, providing rebase support has significant technical challenges. Bryan outlines this in more detail above, but in a nutshell: currently Bitbucket works with bare repos on the server side. To apply a rebase we'd need to create a working copy on the server, and that isn't a cheap operation. It's not a hard no to this improvement ever happening, but the challenge is a pretty substantial one.

Rebase instead of merge when bringing your feature branch up to date with it's parent

This is something that Bitbucket Server doesn't really play a part in currently. It doesn't force a workflow, but it doesn't facilitate it either. The operation can be done locally and there's generally no reason to bring pull requests into the workflow here. That doesn't mean we can't make it better, but the same technical challenges apply.

I completely agree with David Harper on not forcing workflows upon the users.

There are two different directions for this request.

• Rebase when merging back into the base branch via a Pull Request
• Rebase instead of merge when bringing your feature branch up to date with it's parent

Bitbucket currently assumes you want to do 'merge' in both instances. It gives the users instructions on doing a merge when there are conflicts (instead of rebase which is much cleaner and has caused a load of headaches).

The whole application needs to be much less strict regarding forcing workflows upon users.

I think it would be best to implement it the same way Github did:

Users with admin permissions can configure pull request merge options on branches in several ways:

• Allow both merge commits and commit squashing
• Allow only merge commits
• Allow only squash commits

More details https://help.github.com/articles/about-pull-request-merge-squashing/

EDIT: I noticed that for this there is a separate request (BSERV-2810), but I find them similar.

admvendormanagement, votes are an important signal for us, and are one of the factors we use when planning the product roadmap. This suggestion is something we'd like to address at some point and we welcome further feedback.

Feel free to contact me at rbarnes (at atlassian com) if you'd like to discuss in more detail.

This has 246 votes but has not been picked up by the product team. You've got to ask how effective this mechanism is for driving product enhancements...

+1!

@Dirk, I put binaries in the github repository: https://github.com/MatthieuLJ/StashRebaseWorkflow/tree/master/bin

@merillms I have created STASH-7134 as a ticket tracking the request to expose the pull request merge strategy options in the UI, if you're interested.

matthieu that sounds quite good. can you provide a installable version of the plugin?

If anybody is interested, I wrote a plugin for Stash that would enforce a rebase workflow (either strict or with non-fast-foward merges).
All the code is available there: https://github.com/MatthieuLJ/StashRebaseWorkflow
Comments welcome.

+1

+1

I agree with Eddy, I would really like to be able to have this at the project/repository level so each team in my organization can make this choice if they'd like to.

Hi Vladimir,

After posting my comment yesterday I found ticket STASH-2857 in which instructions are provided to setup stash to use git merge --ff instead of git merge --ff-only, which is exactly what we want. The only missing piece would be to have this setting available in the web interface at project and repository level, so we don't have to involve the Stash admin when we want to change this setting.

Thanks for your help.

You can already prevent an extra merge being created for fast-forward merges: https://confluence.atlassian.com/display/STASH/Stash+config+properties#Stashconfigproperties-Pullrequests

In our team we use the ff-only option and get the developers to rebase locally. This does mean a force push is required for the personal fork however but we have tooling around that. We feel it is safer to do this because the merge is always done by the developer not by Stash, and when the diff changes (because of a force push or new commits) then the PR gets updated.

One of git merge's strengths is that it can be run on this type of "empty" working copy and produce correct results (to do that it checks out only the files that actually need merging; any file it can fast-forward "merge" is never even written to disk). That allows us to write performant algorithms based on it.

What we find problematic is the fact that even if a fast-forward merge is possible, Stash will always create an unnecessary merge commit instead of doing a fast-forward. We don't mind to have merges when there are feature branches indeed developed in parallel, but we mind the unnecessary merges when a fast-forward would be possible.

As I understand it, fast-forward merges would not have the doppelganger issue (since the same commits would be on the integration branch) and would not need the working copy since we're not talking about a git rebase on the bare clone, but about a git merge.

So, to summarize, I would be very happy to live with the current pull request model if the merges which could be fast-forward merges would be resolved as a fast forward and no unnecessary merge commit would be added.

Would this be easier to implement?

Sam's idea seems good to me too, you should create a new issue for that. I guess that it could also use a Smart Commits-like syntax to let Stash know that the pull-request has been closed succesfully despite it was not merged.

Note: smart commits are not available in stash, see STASH-2490.

Hi Kyle,
You are correct, for merging externally everything's wonderful. My problem is that I'm rebasing externally, in which case Jira cannot recognize the new commits, and not only does not recognize the merge, but complains that it can no longer merge because of divergence. This, if course, is proper and just how git itself works. However I know things have been merged, and I wish to inform Jira and the pull-request-submitter that this is the case.
Cheers,
Sam

Sam,
Stash should already mark pull requests as closed/merged if you merge externally. You shouldn't need to deny.

In above comment "does try" should have been "does not try".

Hi everyone,
Thanks for looking into this.
For my team's usage, I'd be happy with an "Externally Merged" button, that effectively marks the pull request as accepted and incorporated, but does try to do anything else. This way, when on my own machine and use rebase to clean up a branch I'm pulling in, I can inform Jira and the person that sent the request that their work has been merged.
Right now, I have to "Deny" pull requests to clear them, when in fact the work has been incorporated.
I'm very much open to suggestion for other ways to better accomplish our work flow and have it reflected in Jira.
Sam.

Jaroslaw Rencz and John Fultz,

If you want have a different button backed by your own custom-scripted functionality, you can have that already by implementing a plugin. Stash offers a plugin point at "stash.pull-request.toolbar.actions" where you can add your own buttons (web items) to its pull request bar (the same toolbar where the "Merge" button is). By adding a PullRequestMergeCheck you could prevent people from merging pull requests and instead you can have them use your own button to apply whatever functionality you want. That type of open-ended replacement is not something we're likely to build into the product, however. The idea of "all the responsibility is on the user side" hasn't held true in our experience; when things go wrong, it still comes back to us in support.

Thanks to all four of you for your input so far. If anyone else has anything to add, I'm still listening!

Best regards,
Bryan Turner
Atlassian Stash

A post-script

For those who are a bit deeper into the internals of Git and who are curious about the type of considerations that go into implementing functionality like this, let me illustrate one of the primary reasons git rebase-based functionality isn't in the system today (aside from the potential for things to go sideways whenever a system automates any form of history rewriting).

When Stash merges a pull request, to run git merge it needs a working copy. All of Stash's repositories are managed as bare, however, so they don't have one. It uses a combination of commands to create one, but that working copy is completely empty--none of the files are actually checked out. It's done this way for speed. Checking out every file in a repository to create a full working copy can be extremely expensive, and we don't want users to click "Merge" and then wait 10 minutes while we do the work; that's not a very good user experience. One of git merge's strengths is that it can be run on this type of "empty" working copy and produce correct results (to do that it checks out only the files that actually need merging; any file it can fast-forward "merge" is never even written to disk). That allows us to write performant algorithms based on it.

git rebase, on the other hand, will not run in such a working copy. It requires a completely clean work tree, with no staged or unstaged changes, to run. That means in order to use git rebase we have to check out every file in the repository (If you're curious, git cherry-pick has the same restriction, ruling out a poor-man's "rebase" too). This isn't a requirement most users think about, or even realize exists, because they generally have a work tree. However, for Stash, it prevents a pretty severe scalability issue because the #1 performance issue we see from customers already is their server running out of I/O bandwidth. The extra load from setting up and tearing down temporary complete work trees to use git rebase to "merge" a pull request would just compound that (on top of the delay involved in writing all those files).

Bryan,

Thank you for asking. This is how I see things at the moment:

When you ask for a rebase workflow, do you want to keep all the distinct commits?

Yes, each commit should be kept.

How do you see this being configured?

Per repository setting. In example, users may be able to choose the allowed strategies for each repo, such as "Merge" (only merge button visible), "Rebase" (only rebase button visible), or "Both" (both merge and rebase buttons visible).

How do you intend to avoid people "merging" the same commits multiple times?

I would leave this to each team to decide. Maybe Atlassian could collect feedback and, at some point, work out a generic solution based on that, but I wouldn't push too hard on it.

Hope it's generic enough to make sense.

The ability to script the merge button doesn't seem like a bad idea. It certainly allows for lots of flexibility.

Here's another possibility. Add a button that rebases the branch. This rebase operation would go to a page with a dedicated interface that allows squashing/fixups. This squashing/fixup page would double as the confirmation page to warn about the operation and to allow the user to confirm that they really wish to do this. This would not be a merge operation; rather, it would be a destructive operation on the source branch. I.e., you can choose either to rebase (with squashing ability) or to merge.

If a shop wants a rebase-only workflow, then all they would have to do is to set pull requests to be ff-only. I.e.,

plugin.stash-scm-git.pullrequest.merge.strategy=ff-only

If they wanted to mix rebase and non-rebase, maybe only when they wish to squash commits, that would be an option.

The same problem applies when rebate workflow is handled manually.

While discussing this issue in our developer team I came into a solution, though this one is probably not the simplest one:

We have developed a shell script to be run by a maintainer. It rebases the branch onto develope, then rebases develop onto that branch which results in a PR resolved as "merged". Then the script removes the rebased branch from the origin.

Maybe instead of taking the responsibility of creating a possibility to mess up you could just allow to replace the action "Merge" button performs with a custom script? Or add another button for this?
Then all the responsibility is on the user side - if we can mess it up manually then allow us to mess it up automatically the way each of us want (instead of trying to find a silver bullet for it)

ah I got you: I would say that this definitely must be handled by the dev team itself and not by stash...

Dirk,

Re: "the pull-request should have a status", that pull request would have a status. But there's nothing that would prevent you from opening a new pull request from the same source branch to the same target branch, and that pull request would have its own status. From a commits perspective, it would look like it hadn't been merged because the actual commits from the first pull request weren't merged; they were rewritten and their doppelgangers were merged. Hopefully that clarifies my last question a little more.

Best regards,
Bryan Turner
Atlassian Stash

just my personal opinion:

• I definitely want to keep the distinct commits! there should be no squash strategy by default.
• a per-repository configuration would be good for us.
• the pull-request should have a status. If that status is "merged" then everyone knows that pull-request is done and there is no more action needed.

All,

I'm one of the Stash developers. Just wanted to feel out a few things here, if any of you would be kind enough to take a moment.

• When you ask for a rebase workflow, do you want to keep all the distinct commits? Stash already supports a squash strategy that can be configured in stash-config.properties, but that merges all the commits in the pull request into a single new commit on the target branch
• How do you see this being configured? Are you going to select merge versus rebase when you're "merging" a pull request? Or configure it for a given repository and that will just be how all the pull requests work?
• How do you intend to avoid people "merging" the same commits multiple times? When we rebase, everything old is new again, as it were. That means you can open the same pull request again and it will show that it still has the same number of commits that are not on the target branch as it had before, either paired with an empty diff (if the stars all align) or with a diff riddled with conflicts as it tries to apply the same changes again. Is that enough of a clue that you're doing something wrong?

Please note: I'm one of the developers, not a product manager. I'm not backlogging this. I'm asking for some clarifications purely so that I can visualize how changes like these might be integrated, if the feature was implemented.

Best regards,
Bryan Turner
Atlassian Stash

+1

Also very surprised that its not an option in stash

+1. I agree that it would be extremely useful.

This is not to criticize, but I'm quite surprised that the rebase workflow is not supported yet, especially considering that this discussion has been going on for more than one year.

Thank you.

The question is: does it possible to develop and deploy this feature into STASH?
If yes, then what is an Atlassian roadmap for this issue?
If not, we just will be happy with our opensource solution.

We moved to gitlab and just made a small change and now we have rebase in the GitlAB