I made a mistake, no need to create laws or rules. > On May 2, 2020, at 11:21 AM, Tim Brust <timbrust3...@gmail.com> wrote: > > +1 to Niklas suggestion :) > > Sent from my iPhone > >>> On 2. May 2020, at 6:54 PM, Niklas Merz <niklasm...@apache.org> 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#id-.asf.yamlfeaturesforgitrepositories-Mergebuttons >>> >>> Should we roll this out to all repos? >>> >>> May 2, 2020 1:38 PM, "julio cesar sanchez" <jcesarmob...@gmail.com> wrote: >>> >>> 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 <gandhiraja...@gmail.com> >>>> escribió: >>>> >>>> + 1 for squash and merge as it makes the repo history cleaner. >>>> >>>>> On Sat, Oct 5, 2019 at 8:34 PM <raphine...@gmail.com> 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 that cleanup I might re-order the test cases. As >>>> re-ordering produces a noisy diff, I usually isolate it in its own >>>> commit. >>>> I would not want to merge this commit with the others as that would lead >>>> to >>>> a commit with a very incomprehensible diff. So in this case I would favor >>>> leaving the commits separate and doing an actual merge to group them >>>> together in the global history. >>>> >>>> Am Fr., 4. Okt. 2019 um 17:03 Uhr schrieb julio cesar sanchez < >>>> jcesarmob...@gmail.com>: >>>> >>>>> 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 (<er...@apache.org>) >>>>> escribió: >>>>> >>>>>> -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 commits if we wanted to >>>>>> protect branches. There is alternative such keeping master open for >>>>> direct >>>>>> commits and development while creating a protected "production" >>>> branch. >>>>>> Anyways this part of the discussion is off-topic and could be another >>>>>> discussion... Anyways, stated above I am downvoting protected >>>> branches >>>>> for >>>>>> now. >>>>>> >>>>>> +1 for "Squash and merge" >>>>>> Makes a nice single commit with the PR number and without the extra >>>> merge >>>>>> commit. >>>>>> >>>>>> +1 for "Rebase and merge" >>>>>> There are use cases where this can work perfectly. >>>>>> For example, Cordova-Electron has a `draft-2.0.0` branch which is >>>>> targeting >>>>>> the next major release. Major PRs were merged into that branch with >>>>> "Squash >>>>>> and merge". This means all PRs have nice PR# information in the >>>> title. >>>>>> A PR will later be created to merge this branch onto master. "Rebase >>>> and >>>>>> merge" will be used and will not create the merge commit message and >>>> will >>>>>> not squash. >>>>>> >>>>>> -1 for "Create a merge commit" >>>>>> Not in favor of the extra merge commit. I think in most cases one PR >>>>> should >>>>>> focus on one task so that means it could be squashed when there are >>>>>> multiple commits. If "Create a merge commit" is used, each commit >>>> will >>>> be >>>>>> merged and does not contain the PR# in the title. When creating >>>> release >>>>>> notes, I need to manually review those commits to identify what PR it >>>>> came >>>>>> from to include the PR linking. Some times, depending on if they are >>>> all >>>>>> related commits, I need to manually group them and create a >>>> meaningful >>>>>> title for the release notes which I would prefer to have been done >>>>>> beforehand. >>>>>> >>>>>> >>>>>> On Wed, Oct 2, 2019 at 12:51 AM Jesse <purplecabb...@gmail.com> >>>> wrote: >>>>>> >>>>>>> -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 meaningful individual >>>> commit >>>>>>> messages get consolidated into the 1 commit. >>>>>>> >>>>>>> On Tue, Oct 1, 2019 at 8:36 AM Norman Breau < >>>> nor...@normanbreau.com> >>>>>>> wrote: >>>>>>> >>>>>>>> +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 issues that the PR resolves. >>>>>>>> >>>>>>>> +1 for "squash + merge" as a default strategy. >>>>>>>> >>>>>>>> I feel like most of the time having all the individual commits >>>> that >>>>>>>> makes up a PR is not really necessary. Most of the time it's >>>>>>>> bloated with tweaks fixing errors that was introduced during the >>>>>>>> development of the PR or perhaps refactoring for code style, etc. >>>>>>>> If there are instances where squash shouldn't be used, that can >>>>>>>> be decided on a per-case basis in my opinion. >>>>>>>> >>>>>>>> On 2019-10-01 10:37 a.m., Chris Brody wrote: >>>>>>>>> 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 with a >>>> merge >>>>>>>>> commit that shows the PR number. >>>>>>>>> >>>>>>>>> My issue with "rebase and merge" is that the commit history >>>> would >>>>> not >>>>>>>>> show the PR number. >>>>>>>>> >>>>>>>>> I think that having the commits show the PR number would make >>>> it >>>> a >>>>>>>>> little easier for whoever makes the release to make the release >>>>> notes >>>>>>>>> with the PR numbers. >>>>>>>>> >>>>>>>>> Are there any recent examples of "a lot of commits from the >>>> same >>>>> PR >>>>>>>>> with meaningless commit messages when changes were requested"? >>>>>>>>> >>>>>>>>> Maybe off-topic: I wonder if we should look for multiple >>>> committers >>>>>> to >>>>>>>>> approve an external contribution before merging? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Oct 1, 2019 at 7:18 AM julio cesar sanchez >>>>>>>>> <jcesarmob...@gmail.com> wrote: >>>>>>>>>> Last year, Jan started a thread with different topics and one >>>> of >>>>>> them >>>>>>>> was >>>>>>>>>> to have a merge convention. I copy the text: >>>>>>>>>> >>>>>>>>>>> 3. Merge Conventions / Protected Branch: >>>>>>>>>>> Connected to all that is my suggestion to protect the >>>> `master` >>>>>> branch >>>>>>>> so >>>>>>>>>> that by default nobody can commit there - all changes have to >>>> be >>>>>> made >>>>>>>> via >>>>>>>>>> Pull Requests. Pull Requests are by default merged via the >>>>> "Squash + >>>>>>>> Merge" >>>>>>>>>> button / functionality so that all commits are squashed into >>>> one >>>>>> clean >>>>>>>>>> commit per change. This also enforces the commit message >>>>> structure I >>>>>>>> posted >>>>>>>>>> above. (Of course committers can choose to _not_ use Squash + >>>>> Merge >>>>>> if >>>>>>>>>> appropriate for the PR - e.g. when cherry picking commits >>>> from a >>>>>>> release >>>>>>>>>> branch or similar). >>>>>>>>>> >>>>>>>>>>> What do you think about this suggestion? >>>>>>>>>> Looks like we didn't agree on anything, but can we agree now? >>>>>>>>>> >>>>>>>>>> I've checked a few repos and some of them have a lot of >>>> commits >>>>> from >>>>>>> the >>>>>>>>>> same PR with meaningless commit messages when changes were >>>>>> requested, >>>>>>>> plus >>>>>>>>>> the ugly "merge PR ### from YYY" that makes the commit history >>>>> hard >>>>>> to >>>>>>>>>> follow and hard to cherry pick if needed. >>>>>>>>>> >>>>>>>>>> Since I'm not sure if we can protect branches, I'll focus only >>>> on >>>>>> the >>>>>>>> merge >>>>>>>>>> convention. >>>>>>>>>> >>>>>>>>>> Can we all agree on using the "squash + merge" for user PRs, >>>>> unless >>>>>> we >>>>>>>>>> think the different commits makes sense, in this case we >>>> should >>>>> try >>>>>>> the >>>>>>>>>> "rebase and merge" button. >>>>>>>>>> >>>>>>>>>> I vote +1 >>>>>>>>> >>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> Regards, >>>> Gandhi >>>> >>>> "The best way to find urself is to lose urself in the service of others >>>> !!!" >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
