I had updated the options on https://cwiki.apache.org/confluence/display/TRAFODION/Merge+Changes#MergeChanges-Step4:MergeLocally
Notice that you need "This closes #<PR num>" phrase for the Apache automation to mark the PR closed. --Steve > -----Original Message----- > From: Selva Govindarajan [mailto:[email protected]] > Sent: Thursday, July 21, 2016 1:53 PM > To: [email protected] > Subject: RE: Squash commits - > > RE: Squash commits - > > I have attempted -squash earlier. But, didn't note down its implication > earlier. I tried again as follows with recent merge successfully with > squash option. You can omit the -m option too. The author name is > retained > by using reuse-message option of commit. I used the first push commit > message from the PR here. > > The push failed. I should have done git rebase -i. instead of git pull. I > will try this when I have the chance to do it next time. > > Git log looks cleaner just contains the what got merged. > > [centos@gselva-apache-ins incubator-trafodion*]$ git fetch origin > +refs/pull/593/head* > > From https://github.com/apache/incubator-trafodion > > * branch refs/pull/593/head -> FETCH_HEAD > > [ > > [centos@gselva-apache-ins incubator-trafodion]$* git merge --squash** -m > "Merge [TRAFODION-2109] PR 593 Load with log error rows returns SQL error > 2034 at times"** FETCH_HEAD* > > Auto-merging core/sql/bin/SqlciErrors.txt > > Squash commit -- not updating HEAD > > Automatic merge went well; stopped before committing as requested > > [centos@gselva-apache-ins incubator-trafodion]$* git commit --reuse- > message > 37f7789877d7991c73e8d202735d399ab93d8fac* > > [mrg_593_2 a83287b] [TRAFODION-2109] Load with log error rows returns > SQL > error 2034 at times > > Author: selvaganesang <[email protected]> > > 12 files changed, 184 insertions(+), 160 deletions(-) > > [centos@gselva-apache-ins incubator-trafodion*]$** git push apache > HEAD:master* > > Password: > > To https://[email protected]/repos/asf/incubator-trafodion.git > > ! [rejected] HEAD -> master (non-fast-forward) > > error: failed to push some refs to ' > https://[email protected]/repos/asf/incubator-trafodion.git' > > To prevent you from losing history, non-fast-forward updates were rejected > > Merge the remote changes before pushing again. See the 'Note about > > fast-forwards' section of 'git push --help' for details. > > [centos@gselva-apache-ins incubator-trafodion]$* git pull apache master* > > Password: > > From https://git-wip-us.apache.org/repos/asf/incubator-trafodion > > * branch master -> FETCH_HEAD > > Merge made by recursive. > > .../client/transactional/TransactionManager.java | 29 > ++++++++----------- > > .../main/java/org/trafodion/dtm/HBaseTxClient.java | 9 +----- > > 2 files changed, 14 insertions(+), 24 deletions(-) > > [centos@gselva-apache-ins incubator-trafodion]$* git push apache > HEAD:master* > > Password: > > Counting objects: 46, done. > > Delta compression using up to 4 threads. > > Compressing objects: 100% (24/24), done. > > Writing objects: 100% (24/24), 4.09 KiB, done. > > Total 24 (delta 22), reused 0 (delta 0) > > Selva > > -----Original Message----- > From: Hans Zeller [mailto:[email protected] <[email protected]>] > Sent: Monday, July 18, 2016 12:04 PM > To: dev <[email protected]> > Subject: Re: Squash commits > > Hi, > > Sorry to chime in late. I would like to propose that we do NOT squash the > commits in a PR. Instead, we could ask contributors to squash, if their > changes consist of too many commits. > > Here are my reasons: > > 1. Squashing the commits takes away the contributor's commit and makes > > it looks as if the committer implemented the change. IMHO that is > > undesirable, I always liked the fact that our history shows the > > contributors' work very clearly. > > 2. We should not make the commit workflow more complicated. I would > > prefer that contributors do the work, and create a reasonable number of > > commits with clearly defined features. That also makes the review > process > > easier. > > 3. A more minor point: Commits that resolve merge conflicts only should > > start with "Merge". Otherwise (the commit contains actual features not > in > > another commit), the title should not start with "Merge". > > Thanks, > > Hans > > On Fri, Jul 15, 2016 at 9:29 AM, Steve Varnau <[email protected]> > > wrote: > > > I don't think there is a guaranteed way in git. It relies on the > > > committer putting the right info in the commit message. > > > I think the most important thing is the JIRA ID. > > > > > > The message might also contain the commit IDs of the squashed branch > > > commits, but that is harder to recognize, though a search in the log > > > may find it. > > > > > > Also if the committer puts in the magic phrase that causes the Apache > > > automation to close the PR, then the JIRA may also get updated. > > > Again, relying on care taken by the committer. I'm not a big fan of > > > squashed commits because all of this. But it is matter of preference, > > > and they definitely are useful in certain cases. > > > > > > Developers & committers, please, please put the JIRA ID in brackets at > > > the beginning of the line in the PR title and in the merged commit > > > message. And also at least a couple words that describe the change. > > > "fix for JIRA 20112" > > > does not help me a whole lot. > > > "[TRAFODION-20112] compiler NULL fix" is not real specific, but gives > > > a clue and makes sure that the JIRA gets updated with the right PR and > > > commit info! > > > > > > Reviewers, please remind developers to update the PR title to the > > > right format. I see Selva asked someone today. Gold star. > > > > > > --Steve > > > > > > > -----Original Message----- > > > > From: Dave Birdsall [mailto:[email protected] > <[email protected]>] > > > > Sent: Thursday, July 14, 2016 2:25 PM > > > > To: [email protected] > > > > Subject: Squash commits > > > > > > > > Hi, > > > > > > > > > > > > > > > > One thing I’m noticing about squash commits is that the original > > > > pull request does not automatically get updated with the SHA of the > > > > actual merge. > > > > > > > > > > > > > > > > If one needed to cherry-pick the changes to another branch, is there > > > > an easy way to discover the proper SHA? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Dave > > >
