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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 30, 2021, 03:20 UTC
Message-ID: <xmqq7dkke9wa.fsf@gitster.g>
In-Reply-To: <CABPp-BGUrOtHcu-o2xq-3xc3f=9wy2oxcL_4-ays+ejCg8i+sA@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 5 quoted lines

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

Show 5 quoted lines

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