Automatic commit squashing

Horacio Duran horacio.duran at canonical.com
Thu Jun 16 09:05:21 UTC 2016


+1 on Dave's suggestion

On Thursday, 16 June 2016, David Cheney <david.cheney at canonical.com> wrote:

> Counter suggestion: the bot refuses to accept PR's that contain more
> than one commit, then it's up to the submitter to prepare it in any
> way that they feel appropriate.
>
> On Thu, Jun 16, 2016 at 6:44 PM, roger peppe <roger.peppe at canonical.com
> <javascript:;>> wrote:
> > Squashed commits are nice, but there's something worth watching
> > out for: currently the merge commit is committed with the text
> > that's in the github PR, but when a squashed commit is made, this
> > text is ignored and only the text in the actual proposed commit ends up
> > in the history. This surprised me (I often edit the PR description
> > as the review continues) so worth being aware of, I think.
> >
> >   cheers,
> >     rog.
> >
> > On 16 June 2016 at 02:12, Menno Smits <menno.smits at canonical.com
> <javascript:;>> wrote:
> >> Hi everyone,
> >>
> >> Following on from the recent thread about commit squashing and commit
> >> message quality, the idea of automatically squashing commit at merge
> time
> >> has been raised. The idea is that the merge bot would automatically
> squash
> >> commits for a pull request into a single commit, using the PR
> description as
> >> the commit message.
> >>
> >> With this in place, developers can commit locally using any approach
> they
> >> prefer. The smaller commits they make as they work won't be part of the
> >> history the team interacts with in master.
> >>
> >> When using autosquashing the quality of pull request descriptions
> should get
> >> even more scrutiny during reviews. The quality of PR descriptions is
> already
> >> important as they are used for merge commits but with autosquashing in
> place
> >> they will be the *only* commit message.
> >>
> >> Autosquashing can be achieved technically by either having the merge
> bot do
> >> the squashing itself, or by taking advantage of Github's feature to do
> this
> >> (currently in preview mode):
> >>
> >> https://developer.github.com/changes/2016-04-01-squash-api-preview/
> >>
> >> We need to ensure that the squashed commits are attributed to the
> correct
> >> author (i.e. not jujubot). I'm not sure what we do with pull requests
> which
> >> contain work from multiple authors. There doesn't seem to be an
> established
> >> approach for this.
> >>
> >> Thoughts?
> >>
> >> - Menno
> >>
> >>
> >>
> >>
> >> --
> >> Juju-dev mailing list
> >> Juju-dev at lists.ubuntu.com <javascript:;>
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>
> >
> > --
> > Juju-dev mailing list
> > Juju-dev at lists.ubuntu.com <javascript:;>
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com <javascript:;>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160616/120ca85c/attachment.html>


More information about the Juju-dev mailing list