spurious alternate object store warning

[Colin Watson]

<cjwatson@amber ~/src/canonical/launchpad/git (master)>$ git clone lp:launchpad
Cloning into 'launchpad'...
remote: Counting objects: 1234567, done.
remote: Compressing objects: 100% (158539/158539), done.
remote: Total 1234567 (delta 1073965), reused 1234434 (delta 1073905)
Receiving objects: 100% (1234567/1234567), 154.76 MiB | 215.00 KiB/s, done.
Resolving deltas: 100% (1073965/1073965), done.
Checking connectivity... done.
<cjwatson@amber ~/src/canonical/launchpad/git (master)>$ cd launchpad/
<cjwatson@amber ~/src/canonical/launchpad/git/launchpad (master)>$ git remote add bzr-personal lp:~canonical-launchpad-branches/launchpad/+git/bzr-personal
<cjwatson@amber ~/src/canonical/launchpad/git/launchpad (master)>$ git remote update bzr-personal
Fetching bzr-personal
remote: error: /srv/turnip/data/repos/100/turnip-subordinate/objects: ignoring relative alternate object store ../turnip-subordinate/objects
remote: Counting objects: 34933, done.
[...]

It seems to complete successfully, but we should suppress that spurious warning ("error").

[William Grant (wgrant)]

I think the problem is actually a bad assumption in my alternate cloning. It copies the packs but also seems to copy the alternate reference, so this probably occurs on any project whose target references a former target.

[Colin Watson (cjwatson)]

This breaks https outright:

$ git fetch source master
fatal: git fetch_pack: expected ACK/NAK, got 'ERR error: /srv/turnip/data/repos/184/turnip-subordinate/objects: ignoring relative alternate object store ../turnip-subordinate/objects
'

[William Grant (wgrant)]

This is actually more sinister than it seems: a libgit2 local clone of a repo with alternates will just link every file in the objects directory, including info/alternates, leaving the cloned repo without most of its objects. git isn't much better, but it at least makes a relative alternate path absolute so the repo isn't immediately broken.

We'll need to somehow merge the clone_from and its subordinate into a single new subordinate. It may be best to construct subordinates manually rather than using pygit2.clone_repository, especially since we'll need to add and remove packs and refs manually later to keep them up to date.