bq. the original commit is still there, so nothing is really fixed. Though 3 commits didn't look good, the contributor's identity would be retrievable when looking at git history.
Consider this: $ git blame hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfoManagerImpl.java | grep 'se.classification.InterfaceAud' 552400e5 (tedyu 2016-09-12 12:16:26 -0700 60) import org.apache.hadoop.hbase.classification.InterfaceAudience; 552400e5 would lead to: HBASE-16491 A few org.apache.hadoop.hbase.rsgroup classes missing @InterfaceAudience annotation (Umesh Agashe) The downside with force push is that everyone who had the corresponding branch checked out needs to re-check out. This morning I moved a few pending patches out of old work space for master branch (not to lose them when I do rm -rf in the future) and cloned master branch again. My two cents. On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <[email protected]> wrote: > > > > Please never force push to any non-feature branch. I thought we had > > protections to stop force pushes on master and > > have filed INFRA-12602 to get them in place. > > > > > Yeah, I shouldn't have done it. But I think the protection against force > pushes only applies to the "rel/*" namespace. > > > > To fix erroneous commit messages, please revert the offending commits > > and then reapply them with a correct commit message. > > > > > Honestly, I don't see the point of this. In this case the original commit > is still there, so nothing is really fixed. Instead we wind up with 3 > commits muddying up the change history for the affected files. > > I would much rather preserve a clean change history at the cost of a few > bad commit messages. I don't think it's really that big a deal. >
