This might be my lack of expertise in Git (Github). I like the merge commits (when merging a PR) because I can easily find the date when something has been introduced to the code base. Of course, this can also be achieved through Jira tickets and Github PRs history. This means I would not mind adopting the merge and squash option on Github.
On the other hand, regarding the second issue, I prefer the philosophy of single commit PRs; otherwise, it feels pretty hard to track what was introduced by a PR then. I recall seeing PRs with 100+ commits laying around, and I confess that I cannot find myself in the middle of that mayhem.. Daan, could you provide more insights on the benefits of having a commit per change in a PR? On Mon, Jan 8, 2018 at 7:30 PM, Daan Hoogland <daan.hoogl...@shapeblue.com> wrote: > 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 > > > > -- Rafael Weingärtner
