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
