This error:
fatal: cannot convert from utf8 to UTF-8
occured in two distinct situations in our work group with git binaries older
or equal to 1.7.7. Once during a commit, the other time during a rebase. Both
occurences are 100% reproductible. But the commit that gives the error during
a rebase doesn't do so in a cherry-pick.
This is in part our fault: during the standardisation of our git environment,
we (re)enforced UTF-8 encodings by setting "i18n.commitenconding" and
"i18n.logOutputEncoding" to "utf8".
It is the "i18n.logOutputEncoding = utf8" that *sometimes* triggers the error
above.
I know "utf8" is not an accepted denomination ("UTF-8" or "utf-8" should be
used, according to IANA standards), but we have attenuating circumstances in
the fact that most things dealing with encoding accept the erroneous name.
That includes at least iconv(1) and python(1). Thus we ignored that a
distinction existed and, as self-respecting lazy typers, we preferred the (one
touch) shorter version.
I wonder if it should be expected that git accepts these name variants ("utf8"
and "UTF8") as valid and equivalent to the standard ones.
Of course it is very easy for us to work around the error, since setting
"i18n.logOutputEncoding = utf-8" or removing it altogether from the git config
file chases the error away. It's only that these kinds of things are bound to
happen and for a good proportion of git users it might be well opaque,
difficult to fix and, in drastic (user ignorance-induced) cases, a
showstopper.
Thanks for listening.
--
Cristian Tibirna (418) 656-2131 / 4340
Laval University - Québec, CAN ... http://www.giref.ulaval.ca/~ctibirna
Research professional - GIREF ... ctibirna@xxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html