Sounds good, I've just voted for STASH-2874.
Why do I prefer rebase?
1. I can read the history. This is especially important to our team as we need to cherry pick certain commits back to p4. Without a clean history, it's harder to manage that process.
2. Less merge conflicts. We have 14 devs or so all doing pull requests and it would be best if stash would alert the person who raised the pull request if a rebase fails instead of the person doing the merge (we limit access to the main branch so there are only a few devs that handle the merge)

But to be precise, we merge for longer lived branches and rebase for short ones.. longer lived branches have a lot of overhead if it needs to be rebased often... and plus, the history is relatively clear if a merge happens with two branches. It's the short lived ones that throw off the history a lot.

Hi Kenneth,

Thanks for the feedback. In this case I'm closing this issue as a duplicate of STASH-2874 that captures the more general request of enabling rebase based workflows. To keep the Stash UI simple and intuitive we rather not add information that would be irrelevant and potentially confusing to the majority of users who do use the merge based workflow.

If you don't mind me asking, why do you prefer the rebase based workflow over using explicit merges when merging a pull request?

Cheers,
Stefan

Exactly. Our team prefers to rebase and it's quite difficult to know when the pull request branch needs an update.
It would be best to allow pull requests to automatically rebase if it is able to do so without errors, but this feature would at least allow us to know if we need to rebase.

Hi Kenneth,

To clarify what you are after. Are you trying to tell whether the pull request merge will result in a fast forward merge? So when you talk about the parent commit I'm assuming you mean the common ancestor of the source and the target branch which for the fast forward case would be equal to the tip of the target?

Cheers,
Stefan