The user expectation is that the user's host ssh configuration be used.
We are therefore dependent on the host system having ssh and it
functioning correctly. So just use it.
This fixes version mismatches between the ssh shipped in the snap and
the host ssh configuration file format, as well as library dependency
mismatches.
We haven't been setting up LD_LIBRARY_PATH for bash from the core snap,
so host system libraries were being linked. This then breaks on a Focal
host because the libraries needed by bash in the core snap are no longer
available on the host.
We could work around this by setting LD_LIBRARY_PATH, but it is in
general dangerous to call binaries from the core snap from a classic
snap because we don't have control over how they might interact with the
host system.
Instead, we ship bash in our own snap via "stage-packages" and adjust
the shebangs to use this instead.
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.
