You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Bryan Call <bc...@apache.org> on 2020/06/14 15:32:16 UTC
[PROPOSAL] GitHub change to Squash and Merge
I would like to propose that we switch to "Squash and Merge" for GitHub as the only option for merging pull requests. This would mean we would remove the options “Rebase and Merge” and “Create a merge commit”.
When a PR with multiple commits gets merged into the tree without squashing, the release manager needs to track down all of the commits and cherry pick each one of them into the release branch in order. This change would simplify the workflow for the release managers.
Unfortunately GitHub defaults to the last used merge option instead of being to set a default for the project. This is why it is better to remove the other two options.
If you need to have multiple commits to go into the tree for a change, this would require that multiple PRs would have to be created. This should be a rare event.
-Bryan
Re: [PROPOSAL] GitHub change to Squash and Merge
Posted by Leif Hedstrom <zw...@apache.org>.
> On Jun 15, 2020, at 1:45 AM, Masakazu Kitajo <ma...@apache.org> wrote:
>
> Are we ok with anonymous commits like below now? I remember some of us
> didn't like it before.
> https://lists.apache.org/thread.html/930e933eaf6067f4ab70ec8ac3fd439d5d286d13461c1f8a402dfa87%40%3Cdev.trafficserver.apache.org%3E
>
> commit d7345f675012c04e4d7ec36b4eaf6fc825bdf7f8
> Author: Leif Hedstrom <zw...@apache.org>
> AuthorDate: Mon Jun 1 13:19:59 2020 -0600
> Commit: GitHub <no...@github.com>
> CommitDate: Mon Jun 1 13:19:59 2020 -0600
Yeh, I don’t know that we have much of a choice here. What happens is that “GitHub” makes the commit, not the person pushing the “Squash and merge” button? I think we would have to go to the Github PR to actually see who pressed the button. Not ideal, but until they make the merge button always default to “Squash” (and not previously used, which is just dumb), I think this is the best option.
— Leif
Re: [PROPOSAL] GitHub change to Squash and Merge
Posted by Masakazu Kitajo <ma...@apache.org>.
Are we ok with anonymous commits like below now? I remember some of us
didn't like it before.
https://lists.apache.org/thread.html/930e933eaf6067f4ab70ec8ac3fd439d5d286d13461c1f8a402dfa87%40%3Cdev.trafficserver.apache.org%3E
commit d7345f675012c04e4d7ec36b4eaf6fc825bdf7f8
Author: Leif Hedstrom <zw...@apache.org>
AuthorDate: Mon Jun 1 13:19:59 2020 -0600
Commit: GitHub <no...@github.com>
CommitDate: Mon Jun 1 13:19:59 2020 -0600
I'm not 100% sure but it seems like Squash and Merge causes commits like
this.
Masakazu
On Mon, Jun 15, 2020 at 12:32 AM Bryan Call <bc...@apache.org> wrote:
> I would like to propose that we switch to "Squash and Merge" for GitHub as
> the only option for merging pull requests. This would mean we would remove
> the options “Rebase and Merge” and “Create a merge commit”.
>
> When a PR with multiple commits gets merged into the tree without
> squashing, the release manager needs to track down all of the commits and
> cherry pick each one of them into the release branch in order. This change
> would simplify the workflow for the release managers.
>
> Unfortunately GitHub defaults to the last used merge option instead of
> being to set a default for the project. This is why it is better to remove
> the other two options.
>
> If you need to have multiple commits to go into the tree for a change,
> this would require that multiple PRs would have to be created. This should
> be a rare event.
>
> -Bryan
>
>
Re: [PROPOSAL] GitHub change to Squash and Merge
Posted by Brian Neradt <br...@gmail.com>.
+1
On Sun, Jun 14, 2020 at 4:00 PM Evan Zelkowitz <ez...@apache.org> wrote:
> +1
>
> On Sun, Jun 14, 2020 at 2:17 PM Alan Carroll
> <so...@verizonmedia.com.invalid> wrote:
> >
> > +1
> >
> > On Sun, Jun 14, 2020 at 11:27 AM Leif Hedstrom <zw...@apache.org> wrote:
> >
> > > +1
> > >
> > > > On Jun 14, 2020, at 09:32, Bryan Call <bc...@apache.org> wrote:
> > > >
> > > > I would like to propose that we switch to "Squash and Merge" for
> GitHub
> > > as the only option for merging pull requests. This would mean we would
> > > remove the options “Rebase and Merge” and “Create a merge commit”.
> > > >
> > > > When a PR with multiple commits gets merged into the tree without
> > > squashing, the release manager needs to track down all of the commits
> and
> > > cherry pick each one of them into the release branch in order. This
> change
> > > would simplify the workflow for the release managers.
> > > >
> > > > Unfortunately GitHub defaults to the last used merge option instead
> of
> > > being to set a default for the project. This is why it is better to
> remove
> > > the other two options.
> > > >
> > > > If you need to have multiple commits to go into the tree for a
> change,
> > > this would require that multiple PRs would have to be created. This
> should
> > > be a rare event.
> > > >
> > > > -Bryan
> > > >
> > >
> > >
>
--
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30
Re: [PROPOSAL] GitHub change to Squash and Merge
Posted by Evan Zelkowitz <ez...@apache.org>.
+1
On Sun, Jun 14, 2020 at 2:17 PM Alan Carroll
<so...@verizonmedia.com.invalid> wrote:
>
> +1
>
> On Sun, Jun 14, 2020 at 11:27 AM Leif Hedstrom <zw...@apache.org> wrote:
>
> > +1
> >
> > > On Jun 14, 2020, at 09:32, Bryan Call <bc...@apache.org> wrote:
> > >
> > > I would like to propose that we switch to "Squash and Merge" for GitHub
> > as the only option for merging pull requests. This would mean we would
> > remove the options “Rebase and Merge” and “Create a merge commit”.
> > >
> > > When a PR with multiple commits gets merged into the tree without
> > squashing, the release manager needs to track down all of the commits and
> > cherry pick each one of them into the release branch in order. This change
> > would simplify the workflow for the release managers.
> > >
> > > Unfortunately GitHub defaults to the last used merge option instead of
> > being to set a default for the project. This is why it is better to remove
> > the other two options.
> > >
> > > If you need to have multiple commits to go into the tree for a change,
> > this would require that multiple PRs would have to be created. This should
> > be a rare event.
> > >
> > > -Bryan
> > >
> >
> >
Re: [PROPOSAL] GitHub change to Squash and Merge
Posted by Alan Carroll <so...@verizonmedia.com.INVALID>.
+1
On Sun, Jun 14, 2020 at 11:27 AM Leif Hedstrom <zw...@apache.org> wrote:
> +1
>
> > On Jun 14, 2020, at 09:32, Bryan Call <bc...@apache.org> wrote:
> >
> > I would like to propose that we switch to "Squash and Merge" for GitHub
> as the only option for merging pull requests. This would mean we would
> remove the options “Rebase and Merge” and “Create a merge commit”.
> >
> > When a PR with multiple commits gets merged into the tree without
> squashing, the release manager needs to track down all of the commits and
> cherry pick each one of them into the release branch in order. This change
> would simplify the workflow for the release managers.
> >
> > Unfortunately GitHub defaults to the last used merge option instead of
> being to set a default for the project. This is why it is better to remove
> the other two options.
> >
> > If you need to have multiple commits to go into the tree for a change,
> this would require that multiple PRs would have to be created. This should
> be a rare event.
> >
> > -Bryan
> >
>
>
Re: [PROPOSAL] GitHub change to Squash and Merge
Posted by Leif Hedstrom <zw...@apache.org>.
+1
> On Jun 14, 2020, at 09:32, Bryan Call <bc...@apache.org> wrote:
>
> I would like to propose that we switch to "Squash and Merge" for GitHub as the only option for merging pull requests. This would mean we would remove the options “Rebase and Merge” and “Create a merge commit”.
>
> When a PR with multiple commits gets merged into the tree without squashing, the release manager needs to track down all of the commits and cherry pick each one of them into the release branch in order. This change would simplify the workflow for the release managers.
>
> Unfortunately GitHub defaults to the last used merge option instead of being to set a default for the project. This is why it is better to remove the other two options.
>
> If you need to have multiple commits to go into the tree for a change, this would require that multiple PRs would have to be created. This should be a rare event.
>
> -Bryan
>
Re: [PROPOSAL] GitHub change to Squash and Merge
Posted by Damian Meden <da...@verizonmedia.com.INVALID>.
+1
On Mon, Jun 15, 2020 at 3:49 PM Walt Karas <wk...@verizonmedia.com.invalid>
wrote:
> +1 as long as it doesn't cause uncommented commits.
>
> On Mon, Jun 15, 2020 at 9:43 AM Steven R. Feltner <sf...@godaddy.com>
> wrote:
>
> > +1
> >
> > On 6/14/20, 11:32 AM, "Bryan Call" <bc...@apache.org> wrote:
> >
> > Notice: This email is from an external sender.
> >
> >
> >
> > I would like to propose that we switch to "Squash and Merge" for
> > GitHub as the only option for merging pull requests. This would mean we
> > would remove the options “Rebase and Merge” and “Create a merge commit”.
> >
> > When a PR with multiple commits gets merged into the tree without
> > squashing, the release manager needs to track down all of the commits and
> > cherry pick each one of them into the release branch in order. This
> change
> > would simplify the workflow for the release managers.
> >
> > Unfortunately GitHub defaults to the last used merge option instead
> of
> > being to set a default for the project. This is why it is better to
> remove
> > the other two options.
> >
> > If you need to have multiple commits to go into the tree for a
> change,
> > this would require that multiple PRs would have to be created. This
> should
> > be a rare event.
> >
> > -Bryan
> >
> >
> >
>
Re: [PROPOSAL] GitHub change to Squash and Merge
Posted by Walt Karas <wk...@verizonmedia.com.INVALID>.
+1 as long as it doesn't cause uncommented commits.
On Mon, Jun 15, 2020 at 9:43 AM Steven R. Feltner <sf...@godaddy.com>
wrote:
> +1
>
> On 6/14/20, 11:32 AM, "Bryan Call" <bc...@apache.org> wrote:
>
> Notice: This email is from an external sender.
>
>
>
> I would like to propose that we switch to "Squash and Merge" for
> GitHub as the only option for merging pull requests. This would mean we
> would remove the options “Rebase and Merge” and “Create a merge commit”.
>
> When a PR with multiple commits gets merged into the tree without
> squashing, the release manager needs to track down all of the commits and
> cherry pick each one of them into the release branch in order. This change
> would simplify the workflow for the release managers.
>
> Unfortunately GitHub defaults to the last used merge option instead of
> being to set a default for the project. This is why it is better to remove
> the other two options.
>
> If you need to have multiple commits to go into the tree for a change,
> this would require that multiple PRs would have to be created. This should
> be a rare event.
>
> -Bryan
>
>
>
Re: [PROPOSAL] GitHub change to Squash and Merge
Posted by "Steven R. Feltner" <sf...@godaddy.com>.
+1
On 6/14/20, 11:32 AM, "Bryan Call" <bc...@apache.org> wrote:
Notice: This email is from an external sender.
I would like to propose that we switch to "Squash and Merge" for GitHub as the only option for merging pull requests. This would mean we would remove the options “Rebase and Merge” and “Create a merge commit”.
When a PR with multiple commits gets merged into the tree without squashing, the release manager needs to track down all of the commits and cherry pick each one of them into the release branch in order. This change would simplify the workflow for the release managers.
Unfortunately GitHub defaults to the last used merge option instead of being to set a default for the project. This is why it is better to remove the other two options.
If you need to have multiple commits to go into the tree for a change, this would require that multiple PRs would have to be created. This should be a rare event.
-Bryan
Re: [PROPOSAL] GitHub change to Squash and Merge
Posted by Sudheer Vinukonda <su...@yahoo.com.INVALID>.
+1
> On Jun 14, 2020, at 8:32 AM, Bryan Call <bc...@apache.org> wrote:
>
> I would like to propose that we switch to "Squash and Merge" for GitHub as the only option for merging pull requests. This would mean we would remove the options “Rebase and Merge” and “Create a merge commit”.
>
> When a PR with multiple commits gets merged into the tree without squashing, the release manager needs to track down all of the commits and cherry pick each one of them into the release branch in order. This change would simplify the workflow for the release managers.
>
> Unfortunately GitHub defaults to the last used merge option instead of being to set a default for the project. This is why it is better to remove the other two options.
>
> If you need to have multiple commits to go into the tree for a change, this would require that multiple PRs would have to be created. This should be a rare event.
>
> -Bryan
>