If the new approach is adopted, we will likely have to change the functionality of the 'tools' here: https://github.com/apache/cloudstack/tree/master/tools/git
Especially 'git-pr' creates merges with the "would be deprecated" style, so we will probably want to adapt our tracked tooling to conform with any new styles we adopt. Cheers, *Will Stevens* CTO <https://goo.gl/NYZ8KK> On Mon, Jan 15, 2018 at 3:06 PM, Rafael Weingärtner < rafaelweingart...@gmail.com> wrote: > Daan, > > Now that master is open for merges again, can we get a feedback here? It > might be interesting to find a consensus and a standardize way of working > for everybody before we start merging things in master again … > > > > On Mon, Jan 8, 2018 at 8:40 PM, Rafael Weingärtner < > rafaelweingart...@gmail.com> wrote: > > > 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 > > > > > > -- > Rafael Weingärtner >
