From: akpm@linux-foundation.org
Andrew, you have to figure out what we're supposed to do here.
If I "fold in the patch" to avoid breaking bisection, I have to

completely rebase my tree screwing up everyone of my downstream

developers.
Or is this some patch I'm supposed to remember to fold in several

months from now, to some random changeset out of thousands, when the

merge window opens?
Neither option is tenable, and the headaches of neither are

worth it purely for the sake of bisection.
My solution to the bisection problem is to wait a day before pushing

out usually, it's a best effort thing.  I do as many sanity builds as

I can, and we also hope that someone during that day might solve the

problem independantly and post a fix.  That way I can fix it in my

tree locally before the tree goes public.
And I think this is the most reasonable approach.
Once I push something to my public tree, quite frankly, it's the real

deal, it's staying there, and it's a part of the permanent record.

And therefore, we'll put fixes on top.

--

A patch that was sent to wireless-dev among others fixes this problem

I guess it's still stack in the Linville's queue.

http://article.gmane.org/gmane.linux.kernel.wireless.general/14339
Sorry for not catching it earlier.
Thanks

Tomas

---------------------------------------------------------------------

Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for

the sole use of the intended recipient(s). Any review or distribution

by others is strictly prohibited. If you are not the intended

recipient, please contact the sender and delete all copies.
--

What goes into Linus's tree is there for ever and I do think that all

the short-term things we do should be built around making the permanent

record as good as possible.
This is a(nother) case where a toolchain/process problem is forcing us

to do something which we don't want to do.  In an ideal world we should

tell the git developers "we want x, please" and hopefully they can give

it to us.  Because right now, we're having to work around shortcomings

in git and we are producing a lesser product as a result of this.  A tool

should follow the way in which humans want to work, not vice versa.
Short-term...  dunno.  Perhaps you could have a two-weekly

broadly-announced rebase in which you integrate all these dribs and

drags back into their proper place?  Commit them with some well-known

identifier in the title so that they can all be located when that time

comes?
If you announce such a rebase a day or so beforehand then all the guys

who feed into you could get their stuff merged up into your tree to

minimise their pain when the rebase happens, perhaps.
(That being said, this particular no-compile isn't a huge problem - it

can be worked around with a Kconfig change.  But that isn't generally

the case)

--

From: Andrew Morton <akpm@linux-foundation.org>
This has beaten like a dead horse a thousand times.  Bringing
This, along with the idea of taking care of all of the "dribs" right

before the real merge, is error prone.
It means I have to play with large collections of patches all at one

time.  The reason I use GIT is because I'm stupid and make mistakes,

therefore I don't like playing with patches.
I used to play this game, it's a lot of work and it sucks.  One

"drib" can require fixing up 200 patches down the chain.  And

I've had this happen to me all the time in the past when I was

rebasing all the time.
Not this specific case, mind you, but it is a real concern in general.

--

I have to agree with Dave.
Moreover, I used to get regular complaints about the old "regular

rebase" process.  We switched to a "pull and merge" process for 2.6.25,

and in that period nearly all of the process-related complaints

disappeared for me.
To some degree this is a "pick your poison" issue, and for most people

rebasing seems like the deadlier poison.
John

--

John W. Linville

linville@tuxdriver.com

--

Well.  Have you ever been an hour and a half into a bisection at 3AM

then hit a massive oops deep in the TCP code which was spread across a

large number of commits?  I have and it wasn't fun.  iirc I gave up and
Well yes.  We'd like the best of both worlds, only we cannot have it.

And the sole _reason_ we cannot have it is due to restrictions in git

<stimulate, stimulate>.

--