Re: Round-tripping fast-export/import changes commit hashes

On Mon, Mar 1, 2021 at 8:34 PM Junio C Hamano [off-list ref] wrote:

It is just that the output stream of fast-export is designed to be
"filtered" and the expected use case is to modify the stream somehow
before feeding it to fast-import.  And because every object name and
commit & tag signature depends on everything that they can reach,
even a single bit change in an earlier part of the history will
invalidate any and all signatures on objects that can reach it.  So
instead of originally-signed objects whose signatures are now
invalid, "fast-export | fast-import" pipeline would give you
originally-signed objects whose signatures are stripped.

I need to merge two unrelated repos and I am using `reposurgeon`
http://www.catb.org/~esr/reposurgeon/repository-editing.html
to do this preserving timestamps and commit order. The model of
operation is that it reads revisions into memory from git using
fast-export, operates on them, and then rebuild the stream back
into git repo with fast-import. The problem is that in the exported
dump the information is already lost, and the resulting commits are
"not mergeable". Basically all GitHub repositories where people
edited `README.md` online are "not mergeable" after this point,
because all GitHub edited commits are signed.

For my use case, where I just need to attach another branch in
time without altering original commits in any way, `reposurgeon`
can not be used.

Admittedly, there is a narrow use case where such a signature
invalidation is not an issue.  If you run fast-export and feed that
straight into fast-import without doing any modification to the
stream, then you are getting a bit-for-bit identical copy.

I did just that and signatures got stripped, altering history.

git -C protonfixes fast-export --all --reencode=no | (cd
protoimported && git fast-import)

-- 
anatoly t.