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 <purplecabb...@gmail.com> escribió: > 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 > >
