Uploaded image for project: 'Bitbucket Cloud'
  1. Bitbucket Cloud
  2. BCLOUD-12914

Ability to choose between "plain merge" or "git merge --no-ff"

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Hi,
      I noted that Bitbucket UI allow only a "plain merge" instead of "git merge --no-ff".

      As I know, the --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.

      With a "plain merge", it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the current situation, whereas it is easily done if the "--no-ff" flag was used.

      Yes, it will create a few more (empty) commit objects, but the gain is much bigger than the cost.

      Please, can you consdier to add ability for users to toggle merge type in BitBucket?

      I merged some days ago my Develop branch to Master and with BitBucket merge I now find all previous develop commits into merge, while I thought to find only a final big commits on master.

      Thank you

            [BCLOUD-12914] Ability to choose between "plain merge" or "git merge --no-ff"

            waldyrious added a comment - - edited

            This has been finally fixed — see the updated descriptions of BCLOUD-16610, BCLOUD-17881 and BCLOUD-19186, as well as the blog post at https://www.atlassian.com/blog/bitbucket/branch-sync-merge-rebase.

            In fact, it might have been addressed even earlier than that — from the description of this issue, it seems like, at the time, merging a fast-forwardable branch automatically did the fast-forwarding; well, according to https://www.atlassian.com/blog/bitbucket/fast-forward-merges-bitbucket-cloud-default-like, fast-forward merges were explicitly introduced at that time, which means that regular merges should in principle always create a merge commit by contrast.

            dd0c938af01f, or someone from Atlassian, please close this issue as resolved!

             

            waldyrious added a comment - - edited This has been finally fixed — see the updated descriptions of BCLOUD-16610 , BCLOUD-17881 and BCLOUD-19186 , as well as the blog post at https://www.atlassian.com/blog/bitbucket/branch-sync-merge-rebase . In fact, it might have been addressed even earlier than that — from the description of this issue, it seems like, at the time, merging a fast-forwardable branch automatically did the fast-forwarding; well, according to https://www.atlassian.com/blog/bitbucket/fast-forward-merges-bitbucket-cloud-default-like , fast-forward merges were explicitly introduced at that time, which means that regular merges should in principle always create a merge commit by contrast. dd0c938af01f , or someone from Atlassian, please close this issue as resolved!  

            Setting component to Pull requests (I know this applies more broadly, but it's the closest most relevant component).

            Alastair Wilkes added a comment - Setting component to Pull requests (I know this applies more broadly, but it's the closest most relevant component).

              Unassigned Unassigned
              dd0c938af01f ldetomi
              Votes:
              6 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated: