2.6.24 - time to switch

Werner Almesberger werner at openmoko.org
Fri Feb 1 14:17:53 CET 2008

Andy Green wrote:
> Hum apparently this isn't as scary as it sounds,

Excellent !

> Maybe I have the wrong end of the stick, but mokopatch blobs seem to be
> the "tree" in svn.

Yup, so you'd have to interdiff or similar.

That's a problem we currently have because our base hasn't been merged
upstream yet. Upstream will expect us to submit patches that reflect
the final function, without much interest for how we got there, while
our daily work is about incremental changes to our existing
functionality, so we do care very much about the history.

We currenly have the patches more or less separated by function. So
each time an incremental change comes in, I have to break it into
pieces for the functions if affects, apply it to the respective patches
in SVN, then roll up the entire stack and see if it still builds.

That's a problem we didn't have back when almost all the work happened
directly in SVN, since submissions would automatically come broken down
into the right set of changes, with the commit providing the link
between them.

I think that stgit is missing one degree of freedom there, i.e., you
can't have a change that's at the same time per function (SVN: through
the patch file the patch applies to) and per increment (SVN: through
the commit).

Perhaps what would work is to automatically break down each commit into
its component files. E.g., if we had a hypothetical introduce-fiq-gta02,
the FIQ structure renaming would reach me as clean-fiq.patch, which I'd
then manually (*) turn into patches to


in a single commit (let's call it 4010), which you could then
automatically break down into


and at least end up with a sensible structure, but ugly names.

(*) Manually, because there's almost never a 1:1 mapping between the
    source files a patch touches and the quilt patch.

What would help is of course if I got only patches that were excactly
for a single file in SVN, and that clearly said so. But I'm afraid that
may be a bit too much to wish for ;-)

- Werner

More information about the openmoko-kernel mailing list