Thread (53 messages) 53 messages, 6 authors, 2008-06-18

Re: linux-next: Tree for June 5

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2008-06-06 08:32:15
Also in: lkml

On Fri, 6 Jun 2008 18:22:06 +1000 Stephen Rothwell [off-list ref] wrote:
Hi Andrew,

On Fri, 6 Jun 2008 01:01:49 -0700 Andrew Morton [off-list ref] wrote:
quoted
Well yes - I just bodged it by hand then unbodged it later.  But we
have a bisection break there.  Admittedly a minor one, unless the bug
you're bisecting for requires that kprobes be configured.  But it would
be nice to squish it.

I hope Ingo isn't following this
once-you've-checked-it-in-you-can't-fix-it stupidity :(
Its a break caused by the merge of the ftrace tree into the linux-next
tree (because at the point I merge the ftrace tree, linux-next contains
the rcu tree which has moves stuff into rculist.h), so logically that
patch should become part of the merge commit.  If it was part of the
merge, you could never bisect to a point where you got this build
breakage.

Each tree is fine on its own if you go one step back from the merge.
Well OK.  But patches in fact _do_ go into Linux as a single linear
stream of commits.  But the whole git model ignores that reality and
here we see the result.

And saying "git doesn't work like that - you don't understand" just
doesn't cut it.  It is a tool's job to permit humans to implement the
workflow which they wish to follow.  Not to go and force them into
doing something inferior.

Sigh.

/usualrant
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help