got myself into trouble; now what? - how to revert once you've pushed

got myself into trouble; now what? - how to revert once you've pushed

[Robert Buck]

I have a problem where a unexpected merge occurred and got pushed to
our Gitolite repository.

We have two branches: master, feature/wixinstall

Apparently a merge happened from the branch to master (and I am pretty
sure I never typed `git merge...`). But alas, a merge somehow happened
and got pushed.

Then I followed the Git Pro documentation, which said to do this...

    git revert -m 1 [sha_of_C8]

Now I am left with a bigger mess. When I merge master to the branch,
all the newly added files on the branch got deleted (not what I
wanted). Somehow git is interpreting the revert literally as a
sequence of deletes which it incorrectly then applies to the work on
the branch.

What I really wanted the revert to do is restore the history of the
world immediately prior to the merge. But now I have a branch I can't
merge into at all without losing a weeks work.

How can I get out of this mess?

Bob

Re: got myself into trouble; now what? - how to revert once you've pushed

[Jeff King]

On Tue, Mar 01, 2011 at 02:37:19PM -0500, Robert Buck wrote:

> We have two branches: master, feature/wixinstall
> 
> Apparently a merge happened from the branch to master (and I am pretty
> sure I never typed `git merge...`). But alas, a merge somehow happened
> and got pushed.

Did you run "git pull", which is basically fetch+merge?

> Then I followed the Git Pro documentation, which said to do this...
> 
>     git revert -m 1 [sha_of_C8]
> 
> Now I am left with a bigger mess. When I merge master to the branch,
> all the newly added files on the branch got deleted (not what I
> wanted). Somehow git is interpreting the revert literally as a
> sequence of deletes which it incorrectly then applies to the work on
> the branch.

Yeah. That reverts the merge, in essence creating a new tree built on
top of the merge without the results of the merge. But when you try to
re-merge between those two branches, it sees that history has already
combined, and then afterwards eliminated the result. Which is not what
you wanted.

Read the section "reverting the revert" directly below the advice you
followed:

  http://progit.org/2010/03/02/undoing-merges.html

> What I really wanted the revert to do is restore the history of the
> world immediately prior to the merge. But now I have a branch I can't
> merge into at all without losing a weeks work.
> 
> How can I get out of this mess?

If you can accept that history will be rewritten (which is a problem if
people have built on top of your bogus merge), then what you want is:

  git checkout master
  git reset --hard $SHA1_OF_MERGE^

and then re-push.

-Peff

Re: got myself into trouble; now what? - how to revert once you've pushed

[Robert Buck]

On Tue, Mar 1, 2011 at 2:50 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Mar 01, 2011 at 02:37:19PM -0500, Robert Buck wrote:
>
>> We have two branches: master, feature/wixinstall
>>
>> Apparently a merge happened from the branch to master (and I am pretty
>> sure I never typed `git merge...`). But alas, a merge somehow happened
>> and got pushed.
>
> Did you run "git pull", which is basically fetch+merge?
>
>> Then I followed the Git Pro documentation, which said to do this...
>>
>>     git revert -m 1 [sha_of_C8]
>>
>> Now I am left with a bigger mess. When I merge master to the branch,
>> all the newly added files on the branch got deleted (not what I
>> wanted). Somehow git is interpreting the revert literally as a
>> sequence of deletes which it incorrectly then applies to the work on
>> the branch.
>
> Yeah. That reverts the merge, in essence creating a new tree built on
> top of the merge without the results of the merge. But when you try to
> re-merge between those two branches, it sees that history has already
> combined, and then afterwards eliminated the result. Which is not what
> you wanted.
>
> Read the section "reverting the revert" directly below the advice you
> followed:
>
>  http://progit.org/2010/03/02/undoing-merges.html
>
>> What I really wanted the revert to do is restore the history of the
>> world immediately prior to the merge. But now I have a branch I can't
>> merge into at all without losing a weeks work.
>>
>> How can I get out of this mess?
>
> If you can accept that history will be rewritten (which is a problem if
> people have built on top of your bogus merge), then what you want is:
>
>  git checkout master
>  git reset --hard $SHA1_OF_MERGE^
>
> and then re-push.

That does not work; the central server rejects the commit. Now there
are two other commits after mine, and the problem is getting worse.

Does anyone have a detailed guide of how to obliterate a range of
commits and replay subsequent history on top of that?

-Bob

Re: got myself into trouble; now what? - how to revert once you've pushed

[Jeff King]

On Wed, Mar 02, 2011 at 08:10:38AM -0500, Robert Buck wrote:

> > If you can accept that history will be rewritten (which is a problem if
> > people have built on top of your bogus merge), then what you want is:
> >
> >  git checkout master
> >  git reset --hard $SHA1_OF_MERGE^
> >
> > and then re-push.
> 
> That does not work; the central server rejects the commit. Now there
> are two other commits after mine, and the problem is getting worse.

Yeah, you would need "git push -f" to force push the rewrite of history.
But if people are building on top, then you would be removing their
history.

It's also possible that your server is configured to disallow pushing
history rewrites entirely, in which case all of the advice below will be
useless to you.

> Does anyone have a detailed guide of how to obliterate a range of
> commits and replay subsequent history on top of that?

You can do what you want with rebase. But note that this is also
rewriting history, so people building on top of what you rewrite will be
inconvenienced. If you are working a small-ish team where you can tell
everybody "stop what you're doing, let me fix this, and then we'll
proceed with working on top of my new history", then you can do
something like this.

Your history presumably looks something like this:

         T1--T2--T3
         /         \
  ...A--B--C--D--E--M--N1--N2 <-- master

where A..E are commits on master, T1..T3 are commits on the topic branch
that accidentally got merged, M is the merge commit, and N1..N2 are
commits built on top. Presumably your master points at N2. Obviously the
numbers of commits I just made up, but you should be able to identify
the sha1 id of the merge commit, "M".

Though the reflogs will provide a safety net for reversing the changes
we're about to make, it may be simpler to experiment on a new branch,
just in case we screw things up. Then when we have it looking good, we
can put our changes onto the master and topic branches.

So the first thing I would do is:

  git checkout -b new-master master

to make a new branch and check it out. We can also give a name to the
bogus merge commit to make it easier to refer to:

  git tag M <commit sha1 of M>

So now we want to go back to "E", and replay N1 and N2 on top of that.
Because M was a merge of topic to master, we know that E is the first
parent of M, which we can refer to as "M^1". So we can use rebase like:

  git rebase --onto M^1 M

which will take all commits between the merge and the current branch tip
(which should be N1 and N2), and replay them on top of the commit just
prior to the merge. Check the result in "git log" or "gitk", or checking
it out, or whatever makes sense to you. If you're happy, you can force
it into master with:

  git branch -f master new-master

I think you also said you ended up merging the bogus merge back onto the
topic branch. To undo that, probably you want to just move the topic
branch back to T3, where it was just prior to the merge. T3 is the
second parent of the merge, so you can use "M^2".

  git branch -f new-topic M^2

and then check that new-topic looks good, and install it with:

  git branch -f topic new-topic

Now you can push it all upstream with:

  git push -f origin master topic

Everybody else on your team will then want to fetch the new history and
reset their branch pointers to match:

  git fetch origin
  git branch -f master origin/master
  git branch -f topic origin/topic

Note that this will _throw away_ any work they had done that was not in
the rewritten history. If they had more commits that weren't pushed,
they will need to do a rebase. I think "git pull --rebase" will do what
they want, but I've never actually used it myself.

I hope that helps. Let me know if you try it and run into complications,
or if some of my assumptions don't match your situation.

-Peff

Re: got myself into trouble; now what? - how to revert once you've pushed

[Jon Seymour]

Here's the approach I take to backout a merge with a bogus topic
branch. I use this in a large team environment where backtracking the
shared integration branch is simply not an option.

Suppose a topic branch 'topic' was merged with master to produce a
merge and then it was decided that topic was a little half-baked

e.g.

$> git merge topic #1
$> git tag M

$> git checkout -b deliver-topic M^2
$> git diff --full-index M M^1 | git apply --index   # should work if
#1 did not produce a conflict
$> git git commit -m "backout premature delivery of topic"
$> git checkout master
$> git merge deliver-topic  # backouts changes contributed by #1

This assumes that neither the original merge with bogus or the merge
with deliver-topic produce any conflicts.

Then, suppose I fix the original problem with the topic branch by
making additional commits to the original topic branch
that fix the problem.

I then revert the revert on the deliver-topic branch

$> git checkout deliver-topic
$> git revert # revert the backout to restore the deliver-topic to the
same state as the original topic
$> git merge topic # this is the fixed topic
$> git checkout master
$> git merge deliver-topic

The nice thing about using a separate delivery branch to manage the
backouts of prematurely merged topics is that the topic branch
itself stays clean. All the revert and apply logic is confined to a
delivery branch which can be forgotten about once the history moves
on. Yes, the integration branch itself looks a little messy, but
integration branches tend to a look a little messy anyway.

jon.