Jakub Narebski <jnareb@xxxxxxxxx> 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. - 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