In the time it takes to get a patch written, tested, reviewed, etc. Drupal continues evolving. As Drupal evolves, the patches must be kept up to date. For example, imagine a patch that was originally created to make some edits to line 5 in file X. Two releases later the patch should actually edit line 10, not line 5. Now the patch has to be updated, or "re-rolled". Sometimes re-rolling a patch is complex, but usually it's pretty simple. Git provides some handy tools that will let you apply the patch to the version of Drupal it was written for, merge the changes into a newer version, and then re-create the patch.
Before getting started, it helps to have a basic understanding of what we're about to do with Git. Here's a brief overview of what's going on in Git during the patch re-rolling process.
Every saved revision of a Git project is called a 'commit'. Every commit in a project's history has an ID number (Figure 1.1).
When a new Drupal release comes out the project is tagged with the release number, for example,7.4, 7.5, 7.6, 7.7. A tag is just an alias for a commit ID. It is a human readable name assigned to a specific revision of the project. (Figure 1.2).
Before re-rolling a patch, we will find a place in the project's history where the patch applies cleanly. (Figure 1.3)
Next we will create a local working branch, or 'topic' branch, based on a version of the project where our patch applies cleanly. (Figure 1.4)
Then we merge in more recent changes from branch 7.x to our working branch and resolve any conflicts that arise during the merge. (Figure 1.5)
Finally, we re-roll the patch by getting the diff between our local branch and Drupal's development branch. Then we save the new diff as a patch and post it on drupal.org.
(Figure 1.6 shows all the previous diagrams combined into one, in case it's helpful for reference.)
git apply --check 1497310-statistics_config_settings-5.patch
git log -1 --before="March 30, 2012".
git checkout -b cmi-statistics 992692441
git apply --index 1497310-statistics_config_settings-5.patch
git statusto see these changes. Avoid adding files which weren't in the initial branch, like the patch.
git commit -m "Applying patch from issue 1497310 comment 5804956"
git rebase 8.0.x
Everything above the ======= is from the "clean" upstream version. Everything below the ======= is found in the patch you are rerolling. In general, you want to keep what's in the clean upstream version, and then modify it to follow the changed behavior from the patch. This ensures that any other changes that have been made to the upstream version not affecting your patch do not accidentally get undone.
git rebase --continue
git diff 8.0.x cmi-statistics > [description]-[issue-number]-[comment-number].patch
git checkout 8.0.x
git apply --check [description]-[issue-number]-[comment-number].patch
If the patch apply cleanly, you've just re-rolled a patch. Congratulations!.