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

On Thu, Mar 4, 2021 at 3:56 AM Junio C Hamano [off-list ref] wrote:

Johannes Sixt [off-list ref] writes:

quoted

Am 02.03.21 um 22:52 schrieb anatoly techtonik:

quoted

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.

What do you mean by "attach another branch in time"? Because if you
really do not want to alter original commits in any way, perhaps you
only want `git fetch /the/other/repository master:the-other-one-s-master`?

Yeah, I had the same impression.  If a bit-for-bit identical copy of
the original history is needed, then fetching from the original
repository (either directly or via a bundle) would be a much simpler
and performant way.

The goal is to have an editable stream, which, if left without edits, would
be bit-by-bit identical, so that external tools like `reposurgeon` could
operate on that stream and be audited.

Right now, because the repository
https://github.com/simons-public/protonfixes contains a signed commit
right from the start, the simple fast-export and fast-import with git itself
fails the check.

I understand that patching `git` to add `--complete` to fast-import is
realistically beyond my coding abilities, and my only option is to parse
the binary stream produced by `git cat-file --batch`, which I also won't
be able to do without specification.

P.S. I am resurrecting the old thread, because my problem with editing
the history of the repository with an external tool still can not be solved.
-- 
anatoly t.