From: Junio C Hamano Date: Wed, 27 Dec 2006 10:24:07 GMT Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <7v1wml8wmw.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Jakub Narebski writes: > That's a bit bad, as it forces to lose some info... but that > info was not that useful anyway. I am tired of listening to this useless FUD of yours. You lost the information when you pruned away the underlying objects; you are not losing information when you expire the reflog entries that became useless long time ago. > 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. At least that is the idea. Have you spotted a bug, perhaps? >> (shortlog since v1.4.4.3 here) > > I'd rather have description a la "what's cooking" here... Send the summary to the list and I'll append it to the release notes.