hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunil Govindan <sun...@apache.org>
Subject Re: [VOTE] Force "squash and merge" option for PR merge on github UI
Date Thu, 01 Aug 2019 12:53:02 GMT
Hi All

INFRA-18777 is closed and github UI has disabled #1 and #3. Only Squash and
Merge is possible.
Could we start using this option (merge from UI) from now onwards ?

- Sunil

On Mon, Jul 22, 2019 at 10:24 AM Bharat Viswanadham
<bviswanadham@cloudera.com.invalid> wrote:

> +1 for squash and merge.
>
> And if we use Github UI, the original author will be shown as the original
> author of the code, not who clicks the squash and merge.
>
> [image: Screen Shot 2019-07-17 at 11.58.51 AM.png]
>
> Like in the screenshot arp7 committed the change from GithubUI, but the
> author is still been shown as the original author "bharatviswa504".
>
> * ef66e4999f3 N - HDDS-1666. Issue in openKey when allocating block.
> (#943) (2 days ago) <Bharat Viswanadham> <Arpit Agarwal>
> Thanks,
> Bharat
>
>
>
> On Wed, Jul 17, 2019 at 10:20 AM IƱigo Goiri <elgoiri@gmail.com> wrote:
>
>> +1
>>
>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <stevel@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 <elek@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-unsubscribe@hadoop.apache.org
>> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> > >
>> > >
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message