Much like communism, it's still in practice at small territory On Thursday, 16 June 2016, David Cheney <[email protected]> wrote:
> I thought feature branches, like communism, sounded good but had > failed in practice. > > On Thu, Jun 16, 2016 at 7:06 PM, Horacio Duran > <[email protected] <javascript:;>> 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 <[email protected] > <javascript:;>> > > wrote: > >> > >> +1 on Dave's suggestion > >> > >> On Thursday, 16 June 2016, David Cheney <[email protected] > <javascript:;>> > >> 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 < > [email protected] <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 <[email protected] > <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 > >>> >> [email protected] <javascript:;> > >>> >> Modify settings or unsubscribe at: > >>> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev > >>> >> > >>> > > >>> > -- > >>> > Juju-dev mailing list > >>> > [email protected] <javascript:;> > >>> > Modify settings or unsubscribe at: > >>> > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >>> > >>> -- > >>> Juju-dev mailing list > >>> [email protected] <javascript:;> > >>> Modify settings or unsubscribe at: > >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
