[coreboot] [commit] r6550 - in trunk: . conf db db/revpropsdb/revprops/0 db/revs db/revs/0 db/transactionsdb/txn-protorevs hooks locks

[Peter Stuge]

Scott Duplichan wrote:
> Sorry about that commit. I am trying to make a local svn so that
> I can incrementally apply a large change set and end up with a 
> series of patches instead of one huge patch.

This isn't really supported by Subversion. But as Sven points out,
it's very much possible with git. I would be happy to help you withh
this Scott, but to be efficient I think we should maybe work via IRC
or some other form of instant messaging (jabber and MSN would be easy
for me, or even SIP). The process outline is:

1. git clone git://code.coreboot.org/coreboot-git.git
2. cd coreboot-git
3. git checkout -b largechangeset [commitid]
4. git apply largechangeset.patch
5. git add -i
6. git commit
7. goto 5. until completed
8. [potential extra steps, see notes]
9. git format-patch master..


Notes on this:

Step 5. is where you will spend potentially a lot of time to pick out
the parts of largechangeset.patch that you want to include in each
commit. Use the p command to say that you want to select what patch
hunks should be added. Then it asks which files you want to process
for the current commit. Can use lists and spans. 1,4 or 1-20 or 1,3,6-9
The selected files are marked with * and when all files you want to
process are marked with * just hit enter at the Patch update>> prompt.
Then git add -i will show you each hunk in each file, and you can say
if you want to add it all or skip it all or abort the entire
operation or you can even edit this hunk to get only what you want
for this commit. Please read the git add man-page for much better
info on "interactive add" as this is called.

Note that it's easy to run git add -i again to add more hunks before
making the commit, in fact I think it's easier than selectively
"un-add" stuff that has been added, but maybe my git-fu is just weak
there. Also note that if you must edit some hunks then things are
inherently a little more complicated if you don't get the hunk just
right the first time. Then I would suggest to [r]evert (in git add -i)
the entire hunk and try again with [p]atch.


If largechangeset.patch applies cleanly only to an older revision you
want to specify the git commit id for that revision as commitid in 3.
Given svn rev 6551, the corresponding git commit can be found using:

git log -1 --grep svn://svn.coreboot.org/coreboot/trunk@6551

The commit id is on the first line of output.

If doing this and want to forward-port changes to current trunk,
then an extra step is needed in 8. as follows:

8.1.1. git rebase master

During this rebase there may be some conflicts that need to be
resolved:

8.1.2. edit source to resolve conflicts
8.1.3. git rebase --continue
8.1.4. repeat from 8.2.

But if there are no conflicts then the rebase is automatic.


Another potential extra step is that you may want to make some
changes to your commits before generating the patches:

8.2.1. git rebase -i master

This allows to combine commits, rewrite commit messages, or change
the contents of the actual commits. I personally find it easier to
use interactive rebase to fix things up than to get the interactive
add exactly right when multiple commits are heavily intertwined.

Again have a look at git rebase --help under INTERACTIVE, for more
complete description of what this can do. It's pretty powerful.

Feel free to ask questions.


Patrick Georgi wrote:
> We already provide a mirror that people can use. Obviously, git isn't
> attractive enough to migrate people over.

You know better than this. :) In fact I'm pretty sure that those who
already use git are already using the mirror, I know I find it very
handy, but officially (from coreboot) it is still the second class
citizen. I think we can only know how attractive it is if and when a
switch is made. Unfortunately it may not be as easy to keep svn as a
second class citizen if the main repo is using git.

Ie. those who already like git have already migrated, and the rest
will need a gentle push.


//Peter