Hi, Elijah Newren wrote: > Relax the parsing to allow these timezones when using > raw import format; when using --date-format=rfc2822 (which is not the > default), we can continue being more strict about timezones. There are two different use cases here that we may want to distinguish. The original motivation for fast-import was for importing a repository from some non-Git storage system (another VCS, a collection of patches and tarballs, or whatever). Such an importer might use --date-format=raw just because that's simple, to avoid overhead. In that case, the strict parsing seems useful for catching bugs in the importer. "git filter-repo" is for taking an existing repository and modifying it. In this case, it would be *possible* to take an invalid timezone and normalize it to "whatever 'git log' would show", but that's overreaching relative to the caller's intent: the caller has a specific set of history modifications they meant to make, and fixing the time zone wasn't necessarily one of them. To that end, would it make sense for this to be a new date-format (e.g., --date-format=raw-permissive) to avoid regressing behavior in the original case? Thanks and hope that helps, Jonathan
