From: Jakub Narebski Date: Wed, 27 Dec 2006 12:12:15 GMT Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <200612271312.15877.jnareb@gmail.com> In-Reply-To: <7v1wml8wmw.fsf@assigned-by-dhcp.cox.net> Junio C Hamano wrote: > Jakub Narebski writes: >> Junio C Hamano wrote: >>> >>>  - The commits referred to by reflog entries are now protected >>>    against pruning.  The new command "git reflog expire" can be >>>    used to truncate older reflog entries and entries that refer >>>    to commits that have been pruned away previously. >>> >>>    Existing repositories that have been using reflog may get >>>    complaints from fsck-objects; please run "git reflog expire >>>    --all" first to remove reflog entries that refer to commits >>>    that are no longer in the repository before attempting to >>>    repack it. >> >> 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. Sorry, this is a bit of my inner packrat ;-) showing thru. I'd rather use "git reflog expire --pruned" to remove reflog entries which refer to commits which are no longer in the repository; I don't know, perhaps "git reflog expire --all" does that: but there is no Documentation/git-reflog.txt (and I'm not running 'next' nor 'master' but 1.4.4.3). So most probably it is just the case of adding an alias to reflog expire option. >>> - A commit object recorded in non UTF-8 encoding records the >>> encoding i18n.commitencoding specified in the originating >>> repository in a new "encoding" header. This information is >>> used by git-log and friends to reencode the message to UTF-8 >>> when displaying. >> >> 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? Perhaps that is the idea, but that idea is not described in above new feature announcement. "... to reencode the message to UTF-8 when displaying, if needed." would cover it, but perhaps better would be to cover this in more detail: "reencode message to UTF-8 if i18n.commitencoding is not set to something other than UTF-8", or "reencode ... to i18n.commitencoding ... if needed". BTW. what happens for NO_ICONV? Just curious... -- Jakub Narebski Poland