From: Ingo Molnar <mingo@elte.hu>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] kmemcheck: divide and conquer
Date: Mon, 16 Jun 2008 09:10:00 +0200 [thread overview]
Message-ID: <20080616071000.GA9320@elte.hu> (raw)
In-Reply-To: <19f34abd0806152355h65876c54r1ae0aa156e839db2@mail.gmail.com>
* 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
next prev parent reply other threads:[~2008-06-16 7:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 14:00 [RFC][PATCH] kmemcheck: divide and conquer Vegard Nossum
2008-06-14 6:31 ` Ingo Molnar
2008-06-14 8:39 ` Vegard Nossum
2008-06-14 9:00 ` Ingo Molnar
2008-06-14 9:17 ` Vegard Nossum
2008-06-16 5:15 ` Ingo Molnar
2008-06-16 6:55 ` Vegard Nossum
2008-06-16 7:10 ` Ingo Molnar [this message]
2008-06-16 7:20 ` Vegard Nossum
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=20080616071000.GA9320@elte.hu \
--to=mingo@elte.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=tglx@linutronix.de \
--cc=vegard.nossum@gmail.com \
/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