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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.