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

[Elijah Newren <newren@gmail.com>]

Hi,

On Sat, Feb 27, 2021 at 4:37 AM anatoly techtonik <techtonik@gmail.com> wrote:
>
> Hi.
>
> I can't get the same commit hashes after fast-export and then fast-import of
> this repository without any edits https://github.com/simons-public/protonfixes
> I have no idea what causes this, and how to prevent it from happening. Are
> there any workarounds?

Your second commit is signed.  Fast-export strips any extended headers
on commits, such as GPG signatures, because there's no way to keep
them in general.  In the special case that you aren't making *any*
changes to the repository and will import it as-is, you could
theoretically keep the signatures, but you don't need fast-export in
such a case so no one ever bothered to implement commit signature
handling in fast-export and fast-import.  If you make any changes
whatsoever to the commits before the signature (including importing
them to a different system), then the signature would be invalid.

You probably don't want to hear this, but there are no workarounds.

There are also other things that will prevent a simple fast-export |
fast-import pipeline from preserving your history as-is besides signed
commits (most of these are noted in the "Inherited Limitations"
section over at
https://htmlpreview.github.io/?https://github.com/newren/git-filter-repo/blob/docs/html/git-filter-repo.html):

  * any other form of extended header; fast-export only looks for the
headers it knows and exports those
  * grafts and replace objects will just get rewritten (and if they
cause any cycles, those cycles and anything depending on them are
dropped)
  * commits without an author will be given one matching the committer
(hopefully you don't have these, but if you do...)
  * tags that are missing a tagger are also a problem (hopefully you
don't have these, but if you do...)
  * annotated or signed tags outside the refs/tags/ namespace will get
renamed weirdly
  * commits by default are re-encoded into UTF-8, though I notice you
did pass --reencode=no to handle this

Hope that at least explains things for you, even if it doesn't give
you a workaround or a solution.