[openib-general] idea for ofed 1 2 kernel file structure

[Michael S. Tsirkin]

> Quoting Roland Dreier <rdreier at cisco.com>:
> Subject: Re: [openib-general] idea for ofed 1 2 kernel file structure
> 
>  > I looked a current ofed 1.2 kernel tree and there is 1 thing I dislike:
>  > It is hard to see changes that are specific to OFED since we have whole
>  > kernel history mixed in.
> 
> I'm not sure how you have your branches set up, but if you have
> something like a "linus" branch that tracks the upstream kernel, it's
> easy to do stuff like "git log linus.." or "git diff linus.. drivers/infiniband"
> and see the differences that way.

limit to drivers/infiniband is no longer sufficient as we have components
under drivers/net etc.
Another problem is that history-rewriting tools such as git rebase
seem to easily get confused by the complicated linux history.

> Using git that way (which is what it's designed for, after all) seems
> better than some scripts to munge together two trees.

Problem is, OFED kernel code actually consists of 2 parts:
upstream kernel developed separately at lkml and out of kernel components,
developed separately. OFED does not really track linux all the time: we
only update at -RC time.

Mixing such 2 projects together does not seem to be what git was designed for.
For example, when a patch is applied upstream we need to remove it from
fixes. So after I do git pull from upstream I get a broken tree that won't
even build. Not good.

Another problem I'm trying to address is the confusion around what gets
applied as patch and what directly. This way, a bad patch won't even apply.


-- 
MST