Re: linux-next: block tree build failure

[Tejun Heo <tj@kernel.org>]

Hello, James.

James Bottomley wrote:
> No ... postmerge trees are held by maintainers for irreconcilable tree
> conflicts.  You run your standard tree, which can fire at any time in
> the merge window and your postmerge one which pulls in the entangled
> tree and adds your patches on top.   This can only go after the
> conflicting subsystem has also been pulled into linus head.
>
>> Out of curiousity, is there any reason not to use more standard git
>> workflow?
> 
> This is a standard workflow ...

Ah... poor wording from me.  I meant the one based on merging and
monotonic commit accumulation without rebasing.

> it's how we've pretty much always sorted out entanglements ... at
> least it's between me and Jens, which are two git trees ... I've had
> to run post merge trees against gregkh's quilt before now.
>
>> Developers (kernel devs at least) are now pretty comfortable with
>> git and trees merging and splitting off.  I can't really see much
>> value in rebasing these days.
> 
> That depends.  It's not unusual for patches to get dropped or moved
> around in my trees (I try not to do it often) which can't be done
> without rebasing.  That pretty much precludes merging because I need a
> cleanly rebaseable change set.

The only benefit I can see for rebasing these days is cosmetic cleanup
of commit history.  Well, fixing history could help bisection at times
but still I don't think it's anything substantial.  Anyways, it's your
tree and your call.

Jens, how do you wanna proceed here?  And is there anything I can do
to help?

Thanks.

-- 
tejun