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 (43)

  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. Log in to comment