Messages in this thread |  | | Date | Mon, 16 Jun 2008 09:10:00 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC][PATCH] kmemcheck: divide and conquer |
| |
* Vegard Nossum <vegard.nossum@gmail.com> wrote:
> For some reason, there is no <asm/irq_vectors.h> in my repository, so > I assume the change came from another branch. In fact, I should have > included <asm/hw_irq.h>, but that doesn't contain the right > definitions in the tip/auto-test branch. > > Yep, seems to be > > commit 9b7dc567d03d74a1fbae84e88949b6a60d922d82 > Author: Thomas Gleixner <tglx@linutronix.de> > Date: Fri May 2 20:10:09 2008 +0200 > > x86: unify interrupt vector defines > > I also can't seem to get the redefined warnings, so I assume that's > also just an indirect conflict with other -tip changes. > > Right now, I am reluctant to apply your fix because it means that > kmemcheck tree won't build as it is. In general, what's the way to > resolve these things? Do you have another branch, *-fixes, where these > fixlets can go until either of the conflicting changesets are merged > upstream? If so, it seems that that would be the right place for this > patch. Do you agree or do you have another solution? :-)
yes, i solved it the following "Git way": i did a --no-commit merge of the tip/x86/irq tree into the tip/kmemcheck2 branch and then "git-cherry-pick --no-commit"-ed the fix and thus made it a part of that merge commit. This way the build failure is never visible during bisection either.
tip/kmemcheck2 is a temporary topic tree: it contains the pull from your tree and i'm testing it at the moment. It will be renamed to tip/kmemcheck once it has passed testing.
btw., due to kmemcheck not being rebased anymore, this will work out just fine in the future: i can pull fixes from your tree into tip/kmemcheck and it will just all get sorted out by Git, despite the cross-merge to tip/x86/irq.
If you rebased kmemcheck i'd have to do rather difficult (and error-prone and harder to trust) manual merges every time you put a kmemcheck fix into your tree, and any breakages introduced by new kmemcheck fixes would not be easily bisectable either.
Ingo
|  |