Automatic commit squashing
David Cheney
david.cheney at canonical.com
Thu Jun 16 09:08:03 UTC 2016
I thought feature branches, like communism, sounded good but had
failed in practice.
On Thu, Jun 16, 2016 at 7:06 PM, Horacio Duran
<horacio.duran at canonical.com> wrote:
> On second thought, this might be a problem for feature branches but we can
> device a way to tell the bot that something is a fb
>
>
> On Thursday, 16 June 2016, Horacio Duran <horacio.duran at canonical.com>
> wrote:
>>
>> +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>
>>> 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>
>>> > 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
>>> >> Modify settings or unsubscribe at:
>>> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>> >>
>>> >
>>> > --
>>> > Juju-dev mailing list
>>> > Juju-dev at lists.ubuntu.com
>>> > Modify settings or unsubscribe at:
>>> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
More information about the Juju-dev
mailing list