1. Bitbucket Website
  2. Public Issue Tracker
  3. master

Issues

Issue #8995 new

Provide the option to use "git merge --squash" for pull requests (BB-10142)

Roy Truelove
created an issue

Issue #6107 was closed two days after it was opened, and since then has received many +1's to the point where it warrants revisiting.

While the original ticket asked for quite a bit of functionality, given the comments i'd suggest limiting the request to "The ability to squash pull requests".

Comments (86)

  1. Mike Staff

    +1 for a tickbox option. We just started using PR, triggered by a larger team, and this would be super helpful to keep the checkin history easier to read.

  2. Sean King

    +1 for squash merge option, currently we've got a script running to git reset --soft HEAD~[no of commits] && git commit && git push -uf origin branch all pull requests before merging via bitbucket, but that's pretty kludgy and results in a weird history. I think PRs + squash merging for all work is a standard enough workflow to warrant a toggle in bitbucket.

  3. Alex Rousskov

    Jon Mooring, if you need more encouragement or ammunition against skeptics, please note that squash merge support fits the original "simplified interface for code review followed by quick and painless merges" requirement that you have provided in issue #6107. The current Bitbucket implementation actually does not:

    • "simplified interface": Adding a simple checkbox is not going to make the interface complex. As an added bonus, it would make it clear to the user whether the changes are going to be squashed. Currently, one has to search documentation or experiment to figure that out.

    • "code review": Perhaps you write perfect feature branches that contain a single commit and do not need review, only approval. Most folks are not that good. For them, "code review" usually means at least one polishing iteration and, hence, at least two commits. The resulting string of "addressed reviewer request" commits should not be merged separately, of course. Those commits have no stand-alone use or merit in most cases. And if a code review exposes a serious bug (that is later fixed during the same review process), then merging those buggy commits is a lot worse than just increasing commit noise! In summary, code review implies squash merges in most environments.

    • "painless merge": Talk about the pain of watching the master branch filling with polishing commits, fixes of bugs that should have never made it into master in the first place, commits with poorly written commit messages, etc., etc.! And how about the pain of doing simple merge actions (that ought to be automated via the review interface) by hand?!

    Supporting squash merges would also give Bitbucket an advantage over Github in this area. Unless Github starts supporting them first, of course. AFAIK, many Github projects have to torture their contributors with the same "squash your pull request after review" nonsense...

  4. Jessica Hamilton

    In the context of GCI (Google Code In), students submit pull requests for their work to be reviewed. And as this is often their first time with large open source projects, require a lot of follow up commits.

    To add manually squashing their own pull requests on top of teaching them everything else gets very tedious. Or having to do it ourselves (and not all of our mentors are git gurus familiar with having to do this either). We've literally had over 100 different students, and numerous pull requests.

    This feature should be high on your priority lists!!

  5. marc0s

    While it's not fixed, how do you guys do to to locally merge --squash and then close the PR at Bitbucket without declining it? Is it possible?

  6. Lee Robert

    My company opted to pay for github instead of bitbucket primarily because of the fact that there are tools such as pulley that squash and close github pull requests.

  7. David Pfundt

    marc0s, When a feature is complete, we create a temporary "squash" branch off the main development branch. We then use git merge --squash origin/feature/XXX to squash it all into this branch. Our pull requests are then made off the squash branch. If we have more commits arising from the pull request, we will often re-squash and re-submit the pull request. Not ideal, but it's a workaround.

  8. Unas Zole

    I'm surprised this is not possible yet.

    An extreme case I encounter is having newbie developers, not familiar with git at all, willing to contribute to my project. Because they are not familiar with git yet, they will get mixed up, sometimes merging branches by mistake and even putting some commits in the wrong branch (as they forgot to checkout), etc. In the end, using revert commits, they fix it all up and send a pull request.

    Therefore, I get a pull request where the diff is all good, and I'd like to accept it, but the commit history is garbage. It'd really be nice to just tick an option to squash the diff into a single clean commit at merge, rather than ask newbies to rewrite their history. (rewriting history is something which requires a bit of understanding of git, which newbies obviously don't have yet)

    Anyway, it's only one specific use case, but I'm pretty sure this feature would be useful to a lot of people :-)

  9. Umang Dhawan

    +1. In my team, we create PRs for review and once approved, we manually merge squash it, and then decline the PR. Having ability to merge squash from bitbucket itself will be very useful!

  10. David King

    This would be a great feature to help the iterative nature of Feature Driven Development coupled with those of us desiring a clean commit history without any process workarounds.

    Please consider adding this feature I know many of us would be happy to beta test :-)

  11. Joshua Kugler

    I know there are lots of votes, and lots of comments, but I'm adding mine as well. This would be hugely helpful, as we enjoy using the web interface for doing review and final merges.

  12. Jay Banyer

    Any update here? This is, by far, the feature that I would most like to see added to BitBucket. Currently we either have to merge using BitBucket which means we get the full history of the branch, with all the revisions, corrections and reversions, or we can squash merge (which is what we want) outside of BitBucket then decline the pull request, which is ugly and misleading.

    BitBucket staff can we get some feedback please? Is there something that makes a squash merge option more complex than it seems?

  13. Max Wolter

    Just one more example of Atlassion ignoring user feedback for more than a year for a feature that would have a huge impact on customer satisfaction and would involve minimal work to implement.

  14. Arne nl

    +1e6

    Nobody mentions the 'merge commit clutter'. During the lifetime of a feature branch, multiple merges from master into the feature branch are necessary. You get these in your master history when merging a PR. Yuk!

  15. darrin501

    LOL +1 - I'm late to the party but what can I say - I don't want an onerous process and our history IS getting cluttered.

    Atlassian - 221 votes and about 2 years later. I suppose this feature doesn't lead to new customer acquisition but this really would be nice to make your current users happier.

  16. Roy Truelove reporter

    Two questions that pop out at me re: this:

    1) Against which commit would the squash occur?

    In some cases this is unambiguous :

    *
    |
    *    ( will squash to here )
    | \
    *  *
    |  |
    |  *
    |  |
    *  *
       |
       *
    

    But in some cases no:

    *
    |
    *    ( diverged here..)
    | \
    *  *
    | \|
    |  * ( upstream was merged here )
    |  |
    *  *
       |
       *
    

    Is it reasonable for BB to figure out that the squash should happen at diverged here, and also that during the rebase on top of the upstream that it should not conflict on code that was already merged onto the feature branch?

    2) Who should be the commit author?

    Quick answer is that it should be the user who's merging the PR, but the problem with that is that all original authoring information is lost. So if user 'joe' did all the work on the feature branch and user 'sally' did the merge, there's no reference at all to 'joe'.

  17. John Martin

    Hi Roy,

    At my previous company which did not use bitbucket we elected to make the last commit author the author of the squashed commit which shows up on the merge destination. So if 10 people worked on a branch the last person to commit to the branch is the commit owner. This is not entirely a big deal though, as the git merge --squash --author 'joe' command defaults to including the history of the commits as the comment for the squashed commit. Thus you achieve a very clean master git log (Which is our goal Atlassian!!), and still can understand the history of each change by looking at the commit comment.

  18. Alex Rousskov

    Roy Truelove, git itself will answer your first question: BB does not need to know the answer. The BB implementation ought to run the equivalent of the git merge --squash branch command on the target branch and letting git decide what that means (while reporting errors back to the user). In other words, BB should do exactly what it does now when a merge button is pressed, but with a --squash option.

    Why do you think BB needs to make any decisions here? The only BB decision I could think of is validating that the pull request diff the user is seeing corresponds to the current target and feature branch states (if not, BB should ask the user to reload first).

    Your second question is valid:

    • If BB does not want to make commit authorship configurable, then the person executing the squashed merge must be used as the author! There is no other sane/safe "author" in this case. Since we are talking about purposefully forgetting the entire feature branch history, we must assume that any individual branch commit details are not important and are often harmful.

    • If BB wants to make commit authorship configurable, then the suggested default could be either the branch author if there was only one author for all branch commits or the current user (as discussed above). Providing an optional list of all authors (with the number of their branch commits?) would be nice.

    FWIW, the non-configurable implementation would address 98% of our company needs so I would selfishly recommend starting with that simpler option.

    So if user 'joe' did all the work on the feature branch and user 'sally' did the merge, there's no reference at all to 'joe'.

    Counter-argument: Committing references to joe while omitting references to bob (who also worked on the feature branch), is often worse than simply using the merge user as an author and, hence, not relying on git log for code authorship information.

  19. John Martin

    So the original request as highlighted was now posted 3 Years ago. Can we at least get a comment to find out if this will be scheduled? If not just mark it as won't fix and move on as done for the original issue.

    Original Reason for rejection: "Thomas. Pull requests are not intended to be a full replacement for git merge, but rather a simplified interface for code review followed by quick and painless merges."

    This is missing the point for this request considering SDLC in today's CI / CD world. My organization wants to use bitbucket as our audit log for code reviews. We also desire tracking for each change (Jira Item) to be cleanly merged on the master branch for operational support reasons. Git is a very nice way to keep our Developer Operations team updated with our Continuous Intergration and Continuous Deployment strategies. When things go wrong, being able to see the WHOLE change quickly makes a very important difference in the support role. This is our motivating perspective. It prevents us from using bitbucket as our authoritative source for code reviews. In order to use the squash feature all of our pull requests are now "Rejected" and we cannot use bitbucket for source review audit history.

  20. bean5

    Alex Rousskov put it quite well. There isn't much to implement. If people want to accept what git does for a squash, then they are prepared to accept the simplest and v1 implementation of a squash via BB. A second version could add more bells and whistles.

    If I worked at BB, I believe I would have implemented this by now using my free time.

    On the flip-side: If you want to squash, you can just use git to squash and then push it...and lose all per-commit review history. Yeah, current feature doesn't fit a squash model when auditing is involved.

  21. Log in to comment