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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 28 2021, anatoly techtonik wrote:

> On Sat, Feb 27, 2021 at 8:49 PM Elijah Newren <newren@xxxxxxxxx> wrote:
>>
>> 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.

>> 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...

>> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux