Max Kirillov <m...@max630.net> writes:
> * do not limit number of warnings - does not worth complicating the code
Unless the warning leads to a quick "die()", wouldn't this make Git
unusable by spewing a "falling back to verbatim copy" for each and
every line of the message of a commit that has 'encoding' element in
its header in the "git log" output, no?
I suspect that this may be a huge mistake.
> +char *reencode_string_len(const char *in, int insz,
> + const char *out_encoding, const char *in_encoding,
> + int *outsz)
> +{
> + if (!same_encoding(in_encoding, out_encoding))
> + warning("Iconv support is disabled at compile time. It is
> likely that\nincorrect data will be printed or stored in
> repository.\nConsider using other build for this task.");
> + return NULL;
> +}
Hmmm, I suspect this may be seen as regression by those who build
Git without ICONV for performance, knowing that there is nothing in
their data that requires character set conversion.
We'd call same_encoding() every time, which would involve a few
strcasecmp() calls. Originally, we didn't even have a function call
overhead.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
