2.6.24 - time to switch
andy at openmoko.com
Fri Feb 1 14:52:00 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
> Andy Green wrote:
>> 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.
Well it sucks because we lost the other attributes of the patch, the
commit log entry, attribution and although we don't seem to worry much
about it right now, Signed-off-by.
> 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.
Vast and mighty is the suckage and pain level in that system.
> 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).
It's true, but the mokopatches seem to me a terrifying abomination
rather than a feature :-O
A question is if the work you do at the front end of accreting patches
into mokopatch worlds is better done at the moment before we issue a
patch upstream, considering we can use techniques like virtual patch
merging filtered by filesets affected or some other patch-granular
> 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,
Clearly when we compose a nontrivial patchset as the author, we have
choices about how to cut them into layers of patches. But the layers
don't really conform to "seams" that work along file lines.
And a unitary patch we send upstream will not conform to discrete file
borders either -- it might do one function but touch five files and that
is the smallest footprint that is possible, and upstream will be happy
to see that as a single patch. I don't think per-file patches gets you
anywhere good at all.
Going to do some more thinking about it, clearly it is a big question.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel