Re: [PATCH v3 3/3] fast-export, fast-import: implement signed-commits

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 29, 2021, 23:42 UTC
Message-ID: <xmqqim44fyjj.fsf@gitster.g>
In-Reply-To: <CABPp-BHhfT3b=UyWOXACrBb6nw86n74thNAx7DUDF0YNOcA-yA@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 8 quoted lines

> I do get that we might have to use warn-strip as the default anyway
> just because some existing tools might rely on it, but do you have any
> examples outside of git-filter-repo?  Given the filter-repo bug
> reports I've gotten with users being surprised at commit signatures
> being stripped (despite the fact that this is documented -- users
> don't always read the documentation), I'd argue that changing to
> --signed-commits=abort as the default is probably a good bugfix for
> both fast-export and for filter-repo.

Thanks. The "filter-repo already gets bug reports from the users" is a valuable input when deciding if it is reasonable to sell the behaviour change as a bugfix to our users.

Perhaps teaching fast-export to pay attention to two environment variables that say "when no --signed-{tag,commit}=<disposition>" command line option is given, use this behaviour" would be a good enough escape hatch for existing tools and their users, while they are waiting for their tools to get updated with the new option you are planning to add?

Also, I am glad that you brought up another possible behaviour that Luke's patch did not add. Exporting existing signatures that may become invalid and deciding what to do with them on the receiving end would be a good option to have. And that would most likely have to be done at "fast-import" end, as a commit that "fast-export" expected to retain its object name if its export stream were applied as-is may not retain the object name when the export stream gets preprocessed before being fed to "fast-import".