2.6.24 - time to switch

Andy Green andy at openmoko.com
Sat Feb 2 17:31:49 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> Andy Green wrote:
>> It means if we peel off the onion skins that make the mokopatches in
>> order to reapply them in git for history, the inner, earliest patches
>> probably won't apply to a modern 2.6.24 tree (they originally worked
>> with 2.6.0 or whatever), even though the whole onion would.
> 
> No, that doesn't happen. When we change the base tree (or just some
> of our patches underneath other patches by us), the patches in SVN+quilt
> may need to be updated.

Are we talking about the same thing here?  Show me where the "2.6.0" or
whatever kernel tree is in svn?  It ain't there if I understood it.

When we "import into git" therefore we won't be able to import a living
patched tree at each point that patches were committed into svn.

Once we're set up with git, we should be able to revert to a whole tree
of the kernel at any patchlevel, whatever the base kernel version was at
that time we will revert to that too.

> I'm actually not sure how this works in git+stgit, and that's one of
> my bigger concerns regarding the workflow:
> 
> When you helped me to get your patches from the GIT tree, you explained
> that I had to "uncommit" some patches in order to travel backwards. Does
> this really mean that past changes disappear for good from the
> repository (which would sound like "rewriting history"), or how does
> stgit insert those updates on top of existing commits ?

No this confuses two different modes of using git.  uncommit sucks git
commits out of git and into stgit, so it is a patch stack again.  They
are ripped out of git in --hard style.

But the kind of branch we are looking at for this job won't ever do
that... if you want to revert something you have to commit the
"antipatch" for whatever it was you didn't like any more, there
shouldn't be any --hard type forcing.  The task of this kind of branch
is to maintain an unbroken history.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHpJr1OjLpvpq7dMoRAhmgAJ43J4swrydA6lHS2133K+/PImx2KQCeOPtr
kwE4+9qhY+vU9cw4fMdK3ZU=
=fZDj
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list