> Quoting Roland Dreier <[EMAIL PROTECTED]>: > 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
