Hi Jukka,

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.

Please let me know if you need any more information.

Thanks,
Hari

--
Hari Shreedharan

Also, I do have trunk's clone as of just before the concerned commits were pushed.  I am willing to force push it, and we will push the only commit intended to be pushed.
Thanks
Hari

--
Hari Shreedharan
On Wednesday, August 15, 2012 at 12:21 AM, Hari Shreedharan wrote:

> Hi Jukka,
>
> 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.
>
> Please let me know if you need any more information.
>
> Thanks,
> Hari
>
> --
> Hari Shreedharan

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

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

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

Hi Jukka,

The INFRA ticket that I filed for tho: INFRA-5145 was closed as "Won't Fix" by joes4. Could you please help us get trunk reset?  

Thanks,
Hari

--
Hari Shreedharan
On Wednesday, August 15, 2012 at 1:08 AM, Hari Shreedharan wrote:

> 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