It turns out that "git format-patch --stdout ... | git am" does not
correctly round-trip in every case. If a commit message contains
something that looks like a patch, "git am" incorrectly tries to apply
it.
Instead, we can note the commits that need to be rebased at export time
with "git rev-list --reverse", and apply them at import time with "git
cherry-pick". This keeps everything "inside git" instead of
round-tripping through an mbox, working around the problem.
This does mean that the repository to which the import happens must have
the commits available, which commonly would mean that the export
destination repository must be the same as the import source repository.
As it happens, this is always the case for us anyway during a
--reimport, so this will work just fine.
Test rich history preservation unescaped patch bug
If a rich history commit _message_ contains something that looks like a
patch, the current implementation will attempt to apply it even though
it shouldn't. This test checks this case, but fails for now as the bug
exists, so we mark it xfail to verify that the test works.
We will shortly be changing rich history preservation to use
cherry-picks to fix a bug. This will require the same repository to be
used for rich history import as the commits being imported will need to
be present in the repository still. Tests will therefore need to use the
same repository for import as they did for export.
This does rely on the test cleanly and correctly removing all previous
relevant tags in order to properly test the import, making it a little
more error prone, but we have no choice given the new requirement.
Since this was previously the only use for our repo_factory fixture, we
can drop it from the code base, together with its documentation. If it
is needed again later, we can always pull it out of VCS again.
The review command was introduced experimentally during the pre-1.0
development period, however it is not believed to be widely used yet,
lacks test cases, and does not have a complete implementation.
The import-ppa command was introduced experimentally during the pre-1.0
development period, however it is not believed to be widely used, lacks
test cases, and may need additional work to make it commensurate with
the standard commands. For instance, this may be better implemented as
an option flag to the import command.
A workaround for the lack of this command is to run bin/git-dsc-commit
from the source tree.
The import-local command was introduced experimentally during the
pre-1.0 development period, however it is not believed to be widely
used, lacks test cases, and may need additional work to make it
commensurate with standard commands. For instance, this may be better
implemented as an option flag to the import command.
A workaround for lack of the import-local command is to run
bin/git-dsc-commit from the source tree.
I noticed that in the reimport of gpsd, cgit reported
2020-03-18 16:52:59 +0100
...whereas the changelog timestamp said
Wed, 18 Mar 2020 15:52:59 +0100
...so there appeared to be something wrong with the parsing.
It turns out that the timezone component in the changelog was being
ignored because Python's time.strptime() is defined to ignore it. We
must use datetime.strptime() instead. The parsing is therefore entirely
adjusted to use only a datetime object.
This wasn't being caught in tests because the expected test value was
wrong - presumably calculated with the same mistake.
I have verified that, based on the date string given in
gitubuntu/changelog_tests/test_date{1,2}, using:
date +%s -d "Mon, 12 May 2016 08:14:34 -0700"
...does report the value of 1463066074, so all tests are adjusted
accordingly. I have also verified that the above command does mutate the
answer if the timezone is mutated, so it does appear to be correctly
timezone-aware.
While there still a risk that I have calculated the expected value
wrong, hopefully the above test migitates this sufficiently. We do
already have adequate test coverage that will prevent regressions in
Changelog.git_authorship(); the problem was that the expected values in
those tests were wrong and this is now fixed.
