Changes between Version 73 and Version 74 of UsingGitWithWebKit

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

Added some tips for breaking up large patches


  • UsingGitWithWebKit

    v73 v74  
    240240touch $(ls .git/objects/pack/pack-*.idx|sed s/idx/keep/)
     243== Breaking Up Large Patches ==
     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:
     249 \/
     250  T - A - B - C - D
     251                  ^
     252                master
     253                  ^
     254                 HEAD
     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:
     260git branch trunk prepare
     261git checkout prepare
     264(Or you can do this in a single command: `git checkout -b trunk prepare`.)
     268 \/
     269  T - A - B - C - D
     270  ^               ^
     271prepare          master
     272  ^
     273 HEAD
     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.
     278So, perhaps `file1` has some changes in commit C that I'd like to put into my first patch:
     281git checkout -p master~1 file1
     284("`master~1`" means "one commit before master".)
     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:
     289webkit-patch upload -g HEAD..
     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.)
     294Then I'd commit the current patch:
     297git add file1 ChangeLog
     298git commit
     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:
     304git branch -D master # Deletes master
     305git branch -m master # Renames current branch to master
     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.)
     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:
     313git add-reviewer -i trunk
     316Then I'd rebase my patches on top of trunk and commit them back to Subversion:
     319git svn rebase
     320git svn dcommit
     323And finally mark the bugs fixed in Bugzilla:
     326webkit-patch mark-bug-fixed 12345
     327webkit-patch mark-bug-fixed 12346
     328webkit-patch mark-bug-fixed 12347