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

[anatoly techtonik <techtonik@gmail.com>]

On Mon, Mar 1, 2021 at 8:34 PM Junio C Hamano <gitster@pobox.com> 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.