[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1173888698.31159.58.camel@localhost.localdomain>
Date: Wed, 14 Mar 2007 12:11:38 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Chris Wright <chrisw@...s-sol.org>,
Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@....de>,
Glauber de Oliveira Costa <glommer@...il.com>,
Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH 18/18] Straight file moves
On Wed, 2007-03-14 at 08:44 -0700, Linus Torvalds wrote:
>
> On Wed, 14 Mar 2007, Steven Rostedt wrote:
> >
> > Here's a list of files that were moved from either i386 or x86_64 over
> > to the arch/x86 directory.
>
> Well, this means that your patch series doesn't actually *compile* as a
> series.
You're right. I should have kept the "RFC/" part, since the reason for
breaking it up was more for review and comments than to actually apply.
> Also, in case you didn't notice, it's also perfectly fine to have
> "impure" moves, ie a move that not only renames something, but also
> changes something (commonly the comments at the top of the file). Maybe
> you simply didn't have anything like that, but I thought I'd mention it
> just in case you tried to avoid it on purpose.
There were a couple of "impure moves". But those where done with two
different commits. So the git-diff -M produced a "pure move" and then a
patch against the end result. So no, I didn't put in any effort to make
them all "pure" moves. Git did that for me.
>
> The reason I really want the whole series to be compileable is that
> especially with a lot of people using "git bisect", if you have something
> that doesn't compile in the middle, not only does it show that the series
> wasn't a series, it also means that you cannot automate the bisect and you
> need manual intervention.
I usually do always try to make my patches compile for every patch. But
this was a strange case and I wanted it to be more reviewable than
compiling at every stage. But if something can be agreed on, I'll make
sure my next patch series conforms to the "compile at every stage" rule.
Thanks,
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists