Marc-Aurèle and Rafael, I mean both. I know we used to require the first, to
create the release notes in a concise way and we used to ban the other because
it leads to unnavigable revision trees. But now that squash and merge is a
functionality of github one might argue that it doesn’t matter anymore.
Personally, I am against squashing persé, in any case. I am not the law (other
than during some triathlons) so we jointly might decide differently.
On 08/01/2018, 16:50, "Nicolas Vazquez" <nicolas.vazq...@shapeblue.com> wrote:
The same as Rafael described. If it is the second case I would prefer
rebasing the target branch and push force instead of including merge commits in
a PR
Obtener Outlook para Android<https://aka.ms/ghei36>
________________________________
From: williamstev...@gmail.com <williamstev...@gmail.com> on behalf of Will
Stevens <wstev...@cloudops.com>
Sent: Monday, January 8, 2018 11:34:42 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] new way of github working
Just a note Daan. If a PR is merged with the `git pr ####` tool in our
utilities folder, it will automatically include the merge commit. Figured
I should mention that...
*Will Stevens*
CTO
<https://goo.gl/NYZ8KK>
On Mon, Jan 8, 2018 at 8:26 AM, Marc-Aurèle Brothier <ma...@exoscale.ch>
wrote:
> Same opinion as Rafael described.
>
> On Mon, Jan 8, 2018 at 11:30 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I did not fully understand what you meant.
> >
> > Are you talking about the merge commit that can be created when a PR is
> > merged? Or, are you talking about a merge commit that is added to a PR
> when
> > a conflict is solved by its author(s)?
> >
> >
> > I do not have problems with the first type of merge commits. However, I
> > think we should not allow the second type to get into our code base.
> >
> > On Mon, Jan 8, 2018 at 7:45 AM, Daan Hoogland <daan.hoogl...@gmail.com>
> > wrote:
> >
> > > Devs,
> > >
> > > I see a lot of merge master to branch commits appearing on PRs. This
is
> > > against prior (non-hard) agreements on how we work. It is getting to
be
> > the
> > > daily practice so;
> > > How do we feel about
> > > 1. not using merge commits anymore?
> > > 2. merging back as a way of solving conflicts?
> > > and
> > > Do we need to make a policy of it or do we let it evolve, at the risk
> of
> > > having more hard to track feature/version matrices?
> > >
> > > --
> > > Daan
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>
nicolas.vazq...@shapeblue.com
www.shapeblue.com
,
@shapeblue
daan.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
