From: David Brown <davidb@davidb.org>
To: Bill Gatliff <bgat@billgatliff.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Node CRC failures in latest mainline git?
Date: Thu, 31 Jul 2008 19:47:07 -0700 [thread overview]
Message-ID: <20080801024706.GB2296@old.davidb.org> (raw)
In-Reply-To: <4892205F.2080005@billgatliff.com>
On Thu, Jul 31, 2008 at 03:28:15PM -0500, Bill Gatliff wrote:
>I have no idea what all that would be doing, I still don't grok the syntax for
>commits and deltas, and "rebase" in particular always scares me. :)
>Here's what I'm trying:
>
>$ git-checkout -b test-branch 9ee08c2df47c10ba624ff05a6c0f2500748bcb69^2
>$ git rebase 9ee08c2df47c10ba624ff05a6c0f2500748bcb69^
>
>CONFLICT (delete/modify): drivers/mtd/maps/mtx-1_flash.c deleted in HEAD and
>modified in MTD/JFFS2: remove CVS keywords. Version MTD/JFFS2: remove CVS
>When you have resolved this problem run "git rebase --continue".
>If you would prefer to skip this patch, instead run "git rebase --skip".
>To restore the original branch and stop rebasing run "git rebase --abort".
>
>Poking at it more now. Does it look like I'm on the right track, at least?
Yes. Basically, there are merge conflicts that got resolved at the end.
You're trying to linearize that which means you have to figure them out for
the pieces. It's kind of a pain, but this particular one isn't all that
hard.
So, I was able to do this rebase as follows:
$ git rebase 9ee08c2df47^
...
$ git rm drivers/mtd/maps/mtx-1_flash.c
$ git rebase --continue
...
Now we have a real conflict in arch/arm/mach-at91/board-yl-9200.c.
$ vi arch/arm/mach-at91/board-yl-9200.c
What you want is actually the first one, but with the first line changed
to:
static struct atmel_nand_data __initdata yl9200_nand_data = {
(with atmel_nand_data, instead of at91_nand_data).
$ git add arch/arm/mach-at91/board-yl-9200.c
$ git rebase --continue
As a sanity check, I can compare the end result:
$ git diff HEAD..9ee08c2df47c10ba624ff05a6c0f2500748bcb69
and see that at least the end result is the same.
Now
$ git bisect start
$ git bisect bad
$ git bisect good 9ee08c2df47c10ba624ff05a6c0f2500748bcb69^
Bisecting: 28 revisions left to test after this
and that should help you find the problem. No guarantee that each
intermediate commit is quite right. You can either fix them, and then
continue, or 'git bisect skip' ones that don't work, but you might miss the
bad one if it just happened to not compile.
David
next prev parent reply other threads:[~2008-08-01 2:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-31 4:25 Node CRC failures in latest mainline git? Bill Gatliff
2008-07-31 4:44 ` Bill Gatliff
2008-08-01 20:59 ` David Woodhouse
2008-08-01 21:01 ` Bill Gatliff
2008-08-01 21:14 ` David Woodhouse
2008-07-31 4:56 ` David Brown
2008-07-31 20:28 ` Bill Gatliff
2008-08-01 2:47 ` David Brown [this message]
2008-08-01 3:48 ` Bill Gatliff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080801024706.GB2296@old.davidb.org \
--to=davidb@davidb.org \
--cc=bgat@billgatliff.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox