Elijah Newren <newren@xxxxxxxxx> 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".
