-
Suggestion
-
Resolution: Unresolved
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
This has been finally fixed — see the updated descriptions of
BCLOUD-16610,BCLOUD-17881andBCLOUD-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!