Thread (11 messages) 11 messages, 3 authors, 2021-03-03

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

flat view

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-02-28 10:35:58

On Sun, Feb 28 2021, anatoly techtonik wrote:
On Sat, Feb 27, 2021 at 8:49 PM Elijah Newren [off-list ref] wrote:
quoted
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.
Why is it not possible to encode them with base64 and insert into the
stream?
I think Elijah means that in the general case people are using fast
export/import to export/import between different systems or in
combination with a utility like git-filter-repo.

In those cases users are also changing the content of the repository, so
the hashes will change, invalidating signatures.

But there's also cases where e.g. you don't modify the history, or only
part of it, and could then preserve these headers. I think there's no
inherent reason not to do so, just that nobody's cared enough to submit
patches etc.
quoted
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):
Is there any way to check what commits will be altered as a result of
`fast-export` and why? Right now I don't see that it is reported.
I don't think so, but not being very familiar with fast export/import I
don't see why it shouldn't have some option to not munge data like that,
or to report it, if someone cared enough to track those issues & patch
it...
quoted
Hope that at least explains things for you, even if it doesn't give
you a workaround or a solution.
Thanks. That is very helpful to know.

The reason I am asking is because I tried to merge two repos with
`reposurgeon` which operates on `fast-export` data. It is basically
merging GitHub wiki into main repo,

After successfully merging them I still can not send a PR, because
it produces a huge amount of changes, because of the stripped info.
It can be seen here:

https://github.com/simons-public/protonfixes/compare/master...techtonik:master

I tracked this behaviour in `reposurgeon` in this issue
https://gitlab.com/esr/reposurgeon/-/issues/344
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help