git convert: some versions of git use fatal: instead of error:
I saw this behavior with git 1.7.12 on my Mac.
test-convert-git: stabilize corruption of test git repo
This error would show up only intermittently since the
test depended on the order of the directories returned by os.walk.
The damage repository test would delete the first object file it came
across. However, the order of the directory listing is arbitrary (it
seems to depend on the filesystem). This meant that sometimes a commit
object was deleted, sometimes a blob object and sometimes a tree
object.
So, fix by hardcoding which object to delete. Delete a commit object,
a blob object and a tree object in three separate tests.
convert/git: catch errors from modern git-ls-remote (
issue3428)
Since git v1.7.8.2-327-g926f1dd (the change was first released in git
1.7.10), git does not return non-zero when "git ls-remote --tags ..."
is run and the repository is damaged. This causes the "damaged
repository with missing commit" test in test-convert-git.t to
unexpectedly succeed.
Fix by aborting if git outputs any lines beginning with "error:",
which required adding some subprocess use in convert/git.py.
incoming: fix incoming when a local head is remotely filtered (
issue3805)
In its current state discovery may return (remotely) filtered elements
in "common". This has usually no impact as "missing" is kept clear of
filtered elements. However when the "remote" repo is a local repo (disk
accessible, and directly created in memory) the incoming code takes a
shortcut and directly uses the "remote" repo to generate the incoming
output. When some common elements are filtered this led to a crash. We
now ensure we use an unfiltered repository to generate the incoming
output. This does not change the behavior as missing is clear of
filtered revision.
Now that we have proper low level filtering, incoming code needs a
deeper cleanup but it is already planned.