Thanks Jukka for your help. I have filed https://issues.apache.org/jira/browse/INFRA-5145 for this. I have a clone of the git repo till late this evening, so I will push that once the branch is reset.
Thanks Hari -- Hari Shreedharan On Wednesday, August 15, 2012 at 12:58 AM, Hari Shreedharan wrote: > Thanks, Jukka. The merge commits mentioned here aren't really merge commits > in the true sense. I will file an INFRA ticket to reset trunk to a commit > before the merge commits. > > > Thanks > Hari > > -- > Hari Shreedharan > > > On Wednesday, August 15, 2012 at 12:48 AM, Jukka Zitting wrote: > > > Hi, > > > > On Wednesday, August 15, 2012, Hari Shreedharan wrote: > > > It seems like a commit to Flume's git-wip-us repo has created a bunch of > > > merge commits(which were due to some local merges on the committer's > > > local repo) on Flume's git repo. I know that we do have a policy against > > > rewriting history, but I would like to request a reset of the trunk > > > branch to a previous state(as of earlier today), so that we can remove > > > the merge commits and keep the history linear. Only one extra "real" > > > commit was pushed - which will be re-pushed. > > > > > > > > > > By default the Git repositories on git-wip-us are configured to prevent > > rewriting history of the main branch, but you can file an INFRA issue to > > get that done. Simply include the hash of an already existing commit to > > which the branch should be reset. > > > > Alternatively you could simply let the merge commits remain in the history, > > as there's little harm in having them and in many cases (like when working > > on topic branches, etc.) merge commits contain valuable information about > > the evolution of a codebase. > > > > BR, > > > > Jukka Zitting
