Currently we unconditionally port forward rich history, without checking
if parent commits have mutated. This is usually fine for a one-off
reimport which we are only conducting because we are expecting the
commits will mutate anyway. However in the case that commits have not
mutated (such as an immediate reimport of a reimport), this
unnecessarily mutates rich history by bumping forward the committer
dates.
Using "git cherry-pick --ff" prevents this by doing exactly what we
want: a cherry-pick is instead "fast forwarded" in the case that the
parent commit has not mutated.
This makes a reimport of a reimport stable in terms of commit and tag
mutations.
Some rich history contains commits that are empty. These result from a
workflow used by some members of the Ubuntu Server team. For example,
the logwatch upload/7.5.0-2ubuntu1 patchset contains a commit with a
message but no actual change.
"git cherry-pick" will by default refuse to apply these, which makes
sense in the interactive case. However in our case we want to rebase
forward the rich history exactly as it was presented. The
"--allow-empty" and "--allow-empty-message" options will permit this.
Reimports fail during rich history preservation when the rich history
contains empty commits or commits with empty messages, so add xfailing
tests for these cases.
A third edge case is that rich history is rebased and regenerated with
fresh committer dates even when this is not required because there is no
commit mutation. This is LP #1876329. In order to fix this, we will be
short-circuiting some of the logic in "git cherry-pick" in the case that
the parent commit of the commit we are cherry-picking has not changed.
For the above mentioned two new tests as well as the existing
test_preservation_patch_in_message() to be effective, we need to make
sure that the parent is mutated, so test_preservation_patch_in_message()
is adjusted accordingly and the two new tests follow the same pattern. A
third xfailing test is added for this third case.
Every test in rich_history_test.py starts "test_rich_history_". Since
these are all in a file named after this, the "rich_history_" part is
redundant, so can be removed to clean things up.
This routine from the lint module was used in submit and git_repository.
Since this deals with git branch information it fits better with
git_repository than elsewhere.