| 242 | |
| 243 | == Breaking Up Large Patches == |
| 244 | |
| 245 | Let'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 | {{{ |
| 248 | trunk |
| 249 | \/ |
| 250 | T - A - B - C - D |
| 251 | ^ |
| 252 | master |
| 253 | ^ |
| 254 | HEAD |
| 255 | }}} |
| 256 | |
| 257 | What 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 | {{{ |
| 260 | git branch trunk prepare |
| 261 | git checkout prepare |
| 262 | }}} |
| 263 | |
| 264 | (Or you can do this in a single command: `git checkout -b trunk prepare`.) |
| 265 | |
| 266 | {{{ |
| 267 | trunk |
| 268 | \/ |
| 269 | T - A - B - C - D |
| 270 | ^ ^ |
| 271 | prepare master |
| 272 | ^ |
| 273 | HEAD |
| 274 | }}} |
| 275 | |
| 276 | Then 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 | |
| 278 | So, perhaps `file1` has some changes in commit C that I'd like to put into my first patch: |
| 279 | |
| 280 | {{{ |
| 281 | git checkout -p master~1 file1 |
| 282 | }}} |
| 283 | |
| 284 | ("`master~1`" means "one commit before master".) |
| 285 | |
| 286 | I'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 | {{{ |
| 289 | webkit-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 | |
| 294 | Then I'd commit the current patch: |
| 295 | |
| 296 | {{{ |
| 297 | git add file1 ChangeLog |
| 298 | git commit |
| 299 | }}} |
| 300 | |
| 301 | Then 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 | {{{ |
| 304 | git branch -D master # Deletes master |
| 305 | git 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 | |
| 310 | Once 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 | {{{ |
| 313 | git add-reviewer -i trunk |
| 314 | }}} |
| 315 | |
| 316 | Then I'd rebase my patches on top of trunk and commit them back to Subversion: |
| 317 | |
| 318 | {{{ |
| 319 | git svn rebase |
| 320 | git svn dcommit |
| 321 | }}} |
| 322 | |
| 323 | And finally mark the bugs fixed in Bugzilla: |
| 324 | |
| 325 | {{{ |
| 326 | webkit-patch mark-bug-fixed 12345 |
| 327 | webkit-patch mark-bug-fixed 12346 |
| 328 | webkit-patch mark-bug-fixed 12347 |
| 329 | }}} |