Jeff King <peff@xxxxxxxx> writes:
> .... But there are some gotchas:
>
> 1. It's stable only for a given Git version, and with a particular set
> ...
> 2. There is no way to pass pack-objects options down through
> ...
> 3. It will be really slow. We're throwing out all of the deltas and
> ...
There also is 4.
4. We do not control zlib, so even with the same Git binary, the
zlib implementation that is dynamically linked to us is free
to produce better compressed base object (or compressed
delta).
3. is not a downside if the priority of the requestor is about
bit-for-bit reproducibility (iow, "no matter what the cost").
> # print all commits in topological order, with ties broken by
> # committer date, which should be stable. And then follow up with the
> # trees and blobs for each.
> git rev-list --topo-order --objects HEAD >objects
>
> # now print the contents of each object (preceded by its name, type,
> # and length, so there's no chance of weird prepending or appending
> # attacks). We cut off the path information from rev-list here, since
> # the ordered set of objects is all we care about.
> cut -d' ' -f1 objects |
> git cat-file --batch >content
>
> # and then take a hash over that content; this will be unambiguous.
> sha256sum <content
Gross but probably stable ;-)
