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

From: Junio C Hamano <[email-masked]>
Date: Fri, 30 Apr 2021 12:20:05 +0900

Elijah Newren <[email-masked]> writes:

> So, if it's just for filter-repo, then I'd say just change
> fast-export's default now.  If you're concerned with
> --signed-commit=abort being a changed default being too drastic for
> other users or tools, then the environment variable escape hatch
> sounds reasonable to me.

I wasn't specifically worried about any single tool.  It is largely
third-party's business, and my job is to make sure it won't be too
hard for them to adjust to our changes.

Even existing users of filter-repo would probably need such an
escape hatch, as it may not necessarily be possible to update
filter-repo at the same time they update Git.

Unless filter-repo refuses to work with a version of Git that is
newer than what it knows about (which is not quite how I would
prepare a tool for external change, though), that is.

> Combine all these "normalizations" that fast-export/fast-import do
> with the ability for users to process the stream from fast-export to
> fast-import and it becomes clear that the only stage in the pipeline
> that can check the validity of the gpg signatures for the imported
> history is the fast-import step.

Yup.  So I guess we two are in agreement wrt the "ideal world".