sounds good! +1 Regards, Da
> On Jul 17, 2019, at 7:32 PM, Dinesh Chitlangia > <dchitlan...@cloudera.com.invalid> wrote: > > +1, this is certainly useful. > > Thank you, > Dinesh > > > > >> On Wed, Jul 17, 2019 at 10:04 PM Akira Ajisaka <aajis...@apache.org> wrote: >> >> Makes sense, +1 >> >>> On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote: >>> >>> +1. Sounds good to me. >>> >>>> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <elgo...@gmail.com> wrote: >>>> >>>> +1 >>>> >>>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran >> <ste...@cloudera.com.invalid >>>>> >>>> wrote: >>>> >>>>> +1 for squash and merge, with whoever does the merge adding the full >>>> commit >>>>> message for the logs, with JIRA, contributor(s) etc >>>>> >>>>> One limit of the github process is that the author of the commit >> becomes >>>>> whoever hit the squash button, not whoever did the code, so it loses >> the >>>>> credit they are due. This is why I'm doing local merges (With some >> help >>>>> from smart-apply-patch). I think I'll have to explore >> smart-apply-patch >>>> to >>>>> see if I can do even more with it >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <e...@apache.org> >> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Github UI (ui!) helps to merge Pull Requests to the proposed >> branch. >>>>>> There are three different ways to do it [1]: >>>>>> >>>>>> 1. Keep all the different commits from the PR branch and create one >>>>>> additional merge commit ("Create a merge commit") >>>>>> >>>>>> 2. Squash all the commits and commit the change as one patch >> ("Squash >>>>>> and merge") >>>>>> >>>>>> 3. Keep all the different commits from the PR branch but rebase, >> merge >>>>>> commit will be missing ("Rebase and merge") >>>>>> >>>>>> >>>>>> >>>>>> As only the option 2 is compatible with the existing development >>>>>> practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a >> lazy >>>>>> consensus vote: If no objections withing 3 days, I will ask INFRA >> to >>>>>> disable the options 1 and 3 to make the process less error prone. >>>>>> >>>>>> Please let me know, what do you think, >>>>>> >>>>>> Thanks a lot >>>>>> Marton >>>>>> >>>>>> ps: Personally I prefer to merge from local as it enables to sign >> the >>>>>> commits and do a final build before push. But this is a different >>>> story, >>>>>> this proposal is only about removing the options which are >> obviously >>>>>> risky... >>>>>> >>>>>> ps2: You can always do any kind of merge / commits from CLI, for >>>> example >>>>>> to merge a feature branch together with keeping the history. >>>>>> >>>>>> [1]: >>>>>> >>>>>> >>>>> >>>> >> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github >>>>>> >>>>>> >> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org >>>>>> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org >>>>>> >>>>>> >>>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org >> For additional commands, e-mail: common-dev-h...@hadoop.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org