A situation occurred the other week that I had not encountered before when working on a GitHub pull request for the PyNE Python package. The PR (#1270) added a new function to initialize materials by supplying activities of radionuclides. It complements existing methods to create materials from masses or atom fractions.
The new lines of code were in my branch for the PR which was forked from the default
develop branch on PyNE’s GitHub repository. Unbeknown to me at the time, the PyNE team were undertaking a hackathon to prepare for a new PyNE release, and active development was ongoing on a separate branch in the main repository (
0.7.0-rc). Normally everything would be brought in line easily by rebasing the branch for PR (#1270) to the
0.7.0-rc branch ready for merging the PR.
In this instance, however, there had previously been another PR (#1264) merged into the
develop branch subsequent to
0.7.0-rc being branched off. This meant that after rebasing my branch to
0.7.0-rc, the new PR (#1270) branch contained both the commits for the new activity-based material initializations and the irrelevant PR (#1264) commits. Schematically it looked like this:
origin develop branch: A---C \ \ new PR (#1270) branch: \ C-D \ / origin 0.7.0-rc branch: A-B
After rebasing to
0.7.0-rc, the head branch for PR (#1270) presented both the
C commits from PR (#1264) and the
D commits associated with the new activity-to-material functionality.
The way to tidy this up so that only the relevant
D commits for the new functionality were part of PR (#1270) was to perform a git interactive rebase:
git rebase -i HEAD~x
Interactive rebase, among other things, lets you track back and delete previous git commits from the code lineage. Note
x here is the number of commits you choose to track back and process during the interactive rebase. With interactive rebase, the
C commits could be deleted from the head branch for PR (#1270), leaving only the relevant
D commits, thus tidying everything up.