+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 > >