Several Apache project have a script to perform this stuff I really love this kind of scripts You can find an example here (1)
Such scripts: - squash all commits into one - keep original author - ask for a meaningful commit message - interact with JIRA - set Resolved status and fixVersion - all is interactive with very sensible defaults With this kind of script merging a PR is very simple I am using such tools in Zookeeper and Bookkeeper project but I know that other projects have it, they are based on an original script, adapted to the specific rules/habits of a project I also have adapted such scripts to my company projects Enrico (1) https://github.com/apache/zookeeper/blob/master/zk-merge-pr.py Il Sab 14 Mar 2020, 11:22 Robert Scholte <[email protected]> ha scritto: > Yes, once confirmed that the branch builds fine on our Jenkins, we should > do the "squash and merge". (we should already be happy with a proper PR) > My experience so far was like you describe, but it doesn't explain why > Elliotte causes "github" to become the committer. > One possible difference I see is that he's both the author and committer. > I never push my commits via github, but always via gitbox. > > Robert > > On 14-3-2020 04:14:18, Olivier Lamy <[email protected]> wrote: > I agree we must make it mandatory for the committer (us) to squash it. > But not really mandatory to ask contributor to squash but just only use the > "Squash and merge" option and you will get proper commit on merge: > see this commit > > https://github.com/apache/maven-javadoc-plugin/commit/f92b508c26945a0e728fb3b49e87fe216401c9c1 > > > > > On Sat, 14 Mar 2020 at 01:26, Karl Heinz Marbaise wrote: > > > Hi, > > > > On 13.03.20 15:58, Michael Osipov wrote: > > > Am 2020-03-12 um 19:46 schrieb Robert Scholte: > > >> This week I was very surprised to see commits from the user call > > >> "github" in Jenkins: > > >> > > > https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/changes > > >> > > >> > > >> > > >> IMO we shouldn't want these kind of commits. > > >> Based on the most recent activities I had a chat with Sylwester en > > >> Elliotte. > > >> > > >> The reason is the author of these commits was Elliotte, but the > > >> committer Github > > >> > > > https://gitbox.apache.org/repos/asf?p=maven-shared-utils.git&a=commit&h=8ed3e6827885a161a8802100f0f50968555356b0 > > >> > > >> > > >> > > >> Elliotte tried to figure it out, and his conclusion was that in case > > >> he squashed and merged commits via github, the committer became > github. > > >> > > >> If this is indeed the case, we should always ask the author to squash > > >> his commits so we can track the commit better, and it makes it easier > > >> to find possible regressions (and revert them when necessary) > > >> > > >> Not sure if this would help, but my WOW is creating a patch from > > >> github, and applying it to the gitBOX url. Squashing and merging it > > >> from here would at least make me the committer. > > > > > > I highly dislike the squash feature in GitHub because you are out of > > > control of the process. Only, Maven committers, shall be in the > > > committer field. Third parties are not trustworthy for me. > > > > > > Me process for the last couple of years with PRs was > > > > > > * Request a squash from a submitter > > > * Pull that branch into my local clone > > > * Run tests (locally, Jenkins) > > > * Adjust message > > > * Merge into master > > > * Push > > > > > > This gives me full control before this is written to remote. I simply > > > don't trust GH, especially not with these ugly merge commits. > > > > > > M > > > > > > > If I pick a PR from GitHub I simply using the command line > instructions... > > > > I do a `git commit --amend` ...(That makes me the committer of the > > change)...sometimes needed to fix the commit message... > > > > Pushing for testing on Jenkins ...and afterwards merging the single > > commit back to master (no merge commits)... > > > > > > Also what happens here several times is this: (Just an example: > > maven-artifact-transfer): > > > > commit 3338744598e195454f4c5ed1187ea192adfbcf97 > > Author: Piotrek Żygieło > > Commit: Piotrek Żygieło > > > > Remove unused field > > > > So this makes it impossible to check who has integrated that patch into > > the code base... > > > > Or as a different example: > > > > commit a80f5cc026da0e3d98ec720b363728f4509293ff > > Author: Maarten Mulders > > Commit: Karl Heinz Marbaise > > > > [MDEP-626] Upgrade struts and xerces due to CVEs > > o This newer version doesn't depend on struts2-core or xercesImpl. > > o Upgrade Doxia and add doxia-core > > > > > > That shows exactly who has merged that...and who the committer was... > > > > Just my 2 cents. > > > > Kind regards > > Karl Heinz Marbaise > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy >
