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.
Edited by Jacob Vosmaer