Re: [RFH] An early draft of v1.5.0 release notes
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Dec 27, 2006, 11:54 UTC
- Message-ID
- <Pine.LNX.4.63.0612271251060.19693@wbgn013.biozentrum.uni-wuerzburg.de>
- In-Reply-To
- <7v1wml8wmw.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 27 Dec 2006, Junio C Hamano wrote:
Show 14 quoted lines
> Jakub Narebski <jnareb@gmail.com> writes: > > > I don't quite like it. Why if someone uses different encoding > > that utf-8 because his terminal is not set to utf-8? Having suddenly > > what looks like garbage on output, while input was in local encoding > > (and specified in i18n.commitencoding) is a bit suprising... > > If Luben wants UTF-8 in his project, but somebody he pulled from was > mistakenly used latin-1, then the commit pulled record latin-1 while > Luben has i18n.commitencoding in his repository set to UTF-8. Output > will be done in UTF-8 for Luben. For the originator of that latin-1 > commit, i18n.commitencoding says latin-1 (and that was the only reason > he managed to create such a commit) and git show of that commit would > not involve recoding.
I think that this is a misunderstanding. Maybe the config variable is misnamed. As is clearly visible from the commit messages, this whole stuff is meant to reencode to whatever encoding the caller of git-log likes, not just UTF-8. And it defaults to UTF-8, overridable by i18n.commitEncoding.
BTW I think that latin-1 is not a valid encoding name (at least in my setup it isn't), so we should rather talk about iso-8859-1.
Ciao, Dscho