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

Elijah Newren [off-list ref] 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".