Messages in this thread | | | Date | Mon, 1 Mar 2010 09:10:21 +0100 | From | Ingo Molnar <> | Subject | Re: linux-next: current pending merge fix patches |
| |
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> This could also be taken as a reminder to the respective maintiners that > they may want to do a merge of your tree before asking you to pull theirs.
I dont think that's generally correct for trivial conflicts: it's better if Linus does the merge of a tree that is based in some stable tree.
It causes slightly messier criss-cross history: there will be the back-merge commit plus the inevitable merge commit from Linus. It also makes bisection a bit messier:
For example when bisecting i generally consider the 'boundary' of where Linus pulls as a 'known point of stability': i.e. the 'subsystem side' is expected to be well-tested and if there's a problem on that side, it's that subsystem's domain.
"Linus's side", during the merge window, is a rolling tree of many freshly merged trees, which inevitably piles up a few problems.
So it's IMO somewhat better to keep that boundary and not push out Linus's side into subsystem trees: which then may merge a few new patches after having merged Linus's tree, intermixing it all into a non-bisectable combination.
Plus there's also an indirect effect: it keeps people from merging back Linus's tree all the time.
So i'd argue to not backmerge during the merge window (and i have stopped doing that myself a few cycles ago, and it clearly helped things) - but in any case it's certainly no big deal and up to Linus i guess.
Ingo
| |