Re: failure doing massive revert

From: Avery Pennarun <apenwarr@gmail.com>
Date: Sep 18, 2008, 18:26 UTC
Message-ID: <32541b130809181126v4ba4acd7pc5bda085740ab6ba@mail.gmail.com>
In-Reply-To: <1221728946.8516.14.camel@marge.simson.net>

On Thu, Sep 18, 2008 at 5:09 AM, Mike Galbraith <efault@gmx.de> wrote:

Show 6 quoted lines

> For reasons I'd rather not go into, I decided to create a merge free
> tree to try to bisect.  I did this yesterday for a smaller range, and it
> worked fine, and I was able to revert the reverts to re-apply.  Trying
> to revert everything from v2.6.26..today croaked.
>
> for i in `git rev-list --no-merges v2.6.26..HEAD`; do git revert $i < /dev/null; done

Hmm, I don't think you can revert every single patch on a merged tree that way for the same reason you can't just rebase it: history wasn't linear.

I think something involving 'git rev-list --first-parent' and some variant of "git diff $i $i^ | git apply" might work better, as it would inherently squash merge commits, thus making them linearly reversible (although throwing away large parts of history).

Throwing away history might not be what you want, but then again, maybe it is. It's the only way I know of to 100% reliably linearize the history, anyway.

Also, if you use "&& done" instead of "; done" then it'll abort right away when it has a problem.

Have fun,

Avery