It’s not just you Jesse, there are a few in a few repos from different
people. Didn’t mean to attack you, just wanted to remind it as we all agreed
El El sáb, 2 may 2020 a las 20:41, Jesse escribió:
> I made a mistake, no need to create laws or rules.
>
> > On May 2, 2020, at 11:21 AM, Tim Brust
I made a mistake, no need to create laws or rules.
> On May 2, 2020, at 11:21 AM, Tim Brust wrote:
>
> +1 to Niklas suggestion :)
>
> Sent from my iPhone
>
>>> On 2. May 2020, at 6:54 PM, Niklas Merz wrote:
>>>
>>> We could try to enforce this setting with .asf.yml. I saw this posted on
+1 to Niklas suggestion :)
Sent from my iPhone
> On 2. May 2020, at 6:54 PM, Niklas Merz wrote:
>
> We could try to enforce this setting with .asf.yml. I saw this posted on
> another list.
>
> See:
> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#i
We could try to enforce this setting with .asf.yml. I saw this posted on
another list.
See:
https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Mergebuttons
Should we roll this out to all repos?
May 2, 2020 1:38 PM, "
Just a reminder that we agreed on using the squash and merge, but I still
see regular merge commits in a few repos from time to time.
El El sáb, 5 oct 2019 a las 19:32, gandhi rajan
escribió:
> + 1 for squash and merge as it makes the repo history cleaner.
>
> On Sat, Oct 5, 2019 at 8:34 PM wro
+ 1 for squash and merge as it makes the repo history cleaner.
On Sat, Oct 5, 2019 at 8:34 PM wrote:
> +1 for "Squash and merge" as the default strategy
>
> Regarding "Create a merge commit":
> At times, I find this option valuable too. Consider a PR that cleans up a
> test suite. As part of tha
+1 for "Squash and merge" as the default strategy
Regarding "Create a merge commit":
At times, I find this option valuable too. Consider a PR that cleans up a
test suite. As part of that cleanup I might re-order the test cases. As
re-ordering produces a noisy diff, I usually isolate it in its own
Sorry if it wasn't clear, I said I was leaving the protecting master branch
out of the vote.
Looks like we all agree on using "Squash and merge" as default, unless it
makes more sense to use one of the other options.
El jue., 3 oct. 2019 a las 3:43, Bryan Ellis () escribió:
> -1 for protected ma
-1 for protected master branches.
Protecting a branch is a great idea except it does not work with our
current workflow process. COHO commits directly onto the master branch for
releases. We would have to spend more time planning and changing our entire
current workflow process to eliminate direct
-1 for protected master branches, we are a small group of committers and
don't need rules to keep us honest.
Protecting master would involve infra, as we cannot manage the minutia in
github. I think we all do this anyway except for rare occasions.
+1 for squash and merge, as long as the meaningfu
+1 to protect the master branch.
Forcing PR will help organize commits if we need to go back in
time to determine the reason why a change was made as the
commit in github will show the corresponding PR. Which will
(hopefully) be properly filled out with context and motivation,
as well as the issu
I would agree that "squash + merge" should be used in *most* cases,
and I think there is no dispute on this point.
In the few cases where there are too many things for a "squash +
merge" commit, and we have the changes down to a limited number of
clean, sensible commits, then I would favor merging
12 matches
Mail list logo
