Concatenated packfiles may violate uniqueness constraint

Noticed while doing local testing of the pack-objects hook in !1196 (closed), also see &1117 (closed).

This is a show-stopper for &1117 (closed).

It appears that when we naively create a bundle file with git bundle create we can end up with objects that are unreachable, which can then later break clones.

I was not aware of this object uniqueness constraint. I am not sure how we end up violating it.

$ rm -rf test.git; git clone --bare --no-local gitlab-ce.git test.git
Cloning into bare repository 'test.git'...
remote: Enumerating objects: 75, done.
remote: Counting objects: 100% (59/59), done.
remote: Compressing objects: 100% (33/33), done.
remote: Total 33 (delta 21), reused 1 (delta 0)
remote: Pre-computed packfile: 1390720 objects
Receiving objects: 100% (1390753/1390753), 625.97 MiB | 44.19 MiB/s, done.
Resolving deltas: 100% (1045814/1045814), done.
fatal: The same object 343c18f5aa87acbf16810a632bee0172f6dfbdd2 appears twice in the pack
fatal: index-pack failed

The problem here is that 343c18f5aa87acbf16810a632bee0172f6dfbdd2 apparently ended up both in the pre-computed bundle file and in the incremental pack that was computed on the fly.