microplane
microplane copied to clipboard
Squash instead of merge commit
Hello 👋
Thank you for this awesome project! I'd love to contribute to this project, and one thing that has bugged me a little is that I have no way to choose which kind of merge I'd like.
I would rather squash and merge than add a merge commit. I'm not sure if it's possible, but I'd love to have a go at it if that is a feature you'd like to see in Microplane!
Thanks again!
@cobraz
Thanks so much for the suggestion! Yes, I think that is possible, and it would be a nice feature if you'd like to add it.
I imagine usage would look something like
$ mp merge --merge-method squash ...
Here's how I'd go about adding it...
The backend logic for merging happens here
https://github.com/Clever/microplane/blob/948743322ab0dd88ceffb2ebf7b57545bb8e3822/merge/merge.go#L97-L102
You'd want to set mergeMethod: "squash"
within the PullRequestOptions
(see `go-github: https://github.com/google/go-github/blob/a0bec87ef51b4d7f14371d355986c7ca8cd0d84c/github/pulls.go#L440-L441)
Beyond that, we'd want to make sure it's configurable from the CLI command. We can set the merge method via a flag, and default to the existing behavior.
https://github.com/Clever/microplane/blob/948743322ab0dd88ceffb2ebf7b57545bb8e3822/cmd/root.go#L33-L36
https://github.com/Clever/microplane/blob/da8630b14fa3bec8f6efe98ddfea906325bade47/cmd/merge.go#L18-L21
@nathanleiby thank you for the quick reply. I've opened a pull request, hopefully, that works out? :)
See #105
@cobraz Thanks for adding support for this feature!
I realize that we could also add this feature for Gitlab. Sharing some relevant info below, in case you or someone else would like to add it.
During merge, it seems that Gitlab supports merge
(default) or squash
. rebase
isn't handled as a 3rd merge option, but instead must be done separately from the merge.
- https://pkg.go.dev/github.com/xanzy/go-gitlab#MergeRequestsService.AcceptMergeRequest
- https://docs.gitlab.com/ee/api/merge_requests.html#accept-mr
Today in Microplane's Gitlab logic...
If a rebase is possible, we will always do it before merging:
https://github.com/Clever/microplane/blob/bc56dbb2d465340f766debc6781978d0e2e1098b/merge/mergeGitlab.go#L67-L73
We do the merge here (this is where we could pass squash: true
as an option):
https://github.com/Clever/microplane/blob/bc56dbb2d465340f766debc6781978d0e2e1098b/merge/mergeGitlab.go#L78-L80
Suggested Gitlab approach, to give squash support without breaking anything existing:
- always rebase for Gitlab (keep existing behavior)
- if
mergeOption == squash
, thensquash: true
, otherwisesquash: false
Re-opening to track the remaining Gitlab work