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 <
rafaelweingartner@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 <
> rafaelweingartner@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.hoogland@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.Vazquez@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: williamstevens@gmail.com <williamstevens@gmail.com> on behalf
> >> of Will Stevens <wstevens@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 <
> >> marco@exoscale.ch>
> >> wrote:
> >>
> >> > Same opinion as Rafael described.
> >> >
> >> > On Mon, Jan 8, 2018 at 11:30 AM, Rafael Weingärtner <
> >> > rafaelweingartner@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.hoogland@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.Vazquez@shapeblue.com
> >> www.shapeblue.com
> >> ,
> >> @shapeblue
> >>
> >>
> >>
> >>
> >>
> >>
> >> daan.hoogland@shapeblue.com
> >> www.shapeblue.com
> >> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> >> @shapeblue
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Rafael Weingärtner
> >
>
>
>
> --
> Rafael Weingärtner
>
|