Re: [RFH] An early draft of v1.5.0 release notes

From: Junio C Hamano <junkio@cox.net>
Date: Dec 27, 2006, 10:24 UTC
Message-ID: <7v1wml8wmw.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <emtgps$f1q$1@sea.gmane.org>

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