On Thu, 2008-09-18 at 14:26 -0400, Avery Pennarun wrote: > On Thu, Sep 18, 2008 at 5:09 AM, Mike Galbraith <efault@xxxxxx> wrote: > > 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. Ok, nothing is broke, I just tripped over my white git-fu belt. > 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. Thanks, I'll save this reply in case I decide to resume hunt. -Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
