Changes between Version 73 and Version 74 of UsingGitWithWebKit


Ignore:
Timestamp:
Nov 14, 2011 6:58:59 AM (10 years ago)
Author:
Adam Roben
Comment:

Added some tips for breaking up large patches

Legend:

Unmodified
Added
Removed
Modified
  • UsingGitWithWebKit

    v73 v74  
    240240touch $(ls .git/objects/pack/pack-*.idx|sed s/idx/keep/)
    241241}}}
     242
     243== Breaking Up Large Patches ==
     244
     245Let's say you've made a few commits on your master branch while fixing a bug, and now you want to break up those changes into logical patches to post for review:
     246
     247{{{
     248trunk
     249 \/
     250  T - A - B - C - D
     251                  ^
     252                master
     253                  ^
     254                 HEAD
     255}}}
     256
     257What I sometimes do in this case is make a new branch based on trunk (let's name the branch "`prepare`" in this example) and check it out:
     258
     259{{{
     260git branch trunk prepare
     261git checkout prepare
     262}}}
     263
     264(Or you can do this in a single command: `git checkout -b trunk prepare`.)
     265
     266{{{
     267trunk
     268 \/
     269  T - A - B - C - D
     270  ^               ^
     271prepare          master
     272  ^
     273 HEAD
     274}}}
     275
     276Then I'll selectively apply changes from master to my working tree and index using "`git checkout -p`". Just like "`git add -p`" lets you interactively choose chunks of a file to add to the index, "`git checkout -p`" lets you interactively choose chunks of a file from another commit to apply to your working tree and index.
     277
     278So, perhaps `file1` has some changes in commit C that I'd like to put into my first patch:
     279
     280{{{
     281git checkout -p master~1 file1
     282}}}
     283
     284("`master~1`" means "one commit before master".)
     285
     286I'd do this for as many changes/files as I think seem appropriate for the first patch, then write a ChangeLog and upload the patch to Bugzilla:
     287
     288{{{
     289webkit-patch upload -g HEAD..
     290}}}
     291
     292(The "`-g HEAD..`" flag tells webkit-patch only to consider the changes you have in your working tree and index. This is an important flag to pass if you have multiple commits on your current branch that haven't been pushed back to Subversion yet.)
     293
     294Then I'd commit the current patch:
     295
     296{{{
     297git add file1 ChangeLog
     298git commit
     299}}}
     300
     301Then I'd repeat as needed until all the changes from master are represented in my prepare branch and uploaded to Bugzilla. At this point I'd probably delete my master branch and rename prepare to master:
     302
     303{{{
     304git branch -D master # Deletes master
     305git branch -m master # Renames current branch to master
     306}}}
     307
     308(Renaming the branch to master doesn't really make any difference to git, but I find it easier to keep track of things this way.)
     309
     310Once all the changes have been reviewed, I'd use the `Tools/Scripts/git-add-reviewer` script to add the right reviewer names to all the commits on my current branch that are newer than trunk:
     311
     312{{{
     313git add-reviewer -i trunk
     314}}}
     315
     316Then I'd rebase my patches on top of trunk and commit them back to Subversion:
     317
     318{{{
     319git svn rebase
     320git svn dcommit
     321}}}
     322
     323And finally mark the bugs fixed in Bugzilla:
     324
     325{{{
     326webkit-patch mark-bug-fixed 12345
     327webkit-patch mark-bug-fixed 12346
     328webkit-patch mark-bug-fixed 12347
     329}}}