trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selva Govindarajan <>
Subject RE: Squash commits -
Date Thu, 21 Jul 2016 20:53:21 GMT
 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


 * 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

[mrg_593_2 a83287b] [TRAFODION-2109] Load with log error rows returns SQL
error 2034 at times

 Author: selvaganesang <>

 12 files changed, 184 insertions(+), 160 deletions(-)

[centos@gselva-apache-ins incubator-trafodion*]$** git push apache



 ! [rejected]        HEAD -> master (non-fast-forward)

error: failed to push some refs to ''

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*



 * branch            master     -> FETCH_HEAD

Merge made by recursive.

 .../client/transactional/   |   29

 .../main/java/org/trafodion/dtm/ |    9 +-----

 2 files changed, 14 insertions(+), 24 deletions(-)

[centos@gselva-apache-ins incubator-trafodion]$* git push apache


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)


-----Original Message-----
From: Hans Zeller [ <>]
Sent: Monday, July 18, 2016 12:04 PM
To: dev <>
Subject: Re: Squash commits


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


   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".



On Fri, Jul 15, 2016 at 9:29 AM, Steve Varnau <>


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

> > Sent: Thursday, July 14, 2016 2:25 PM

> > To:

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


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