Re: [RFH] An early draft of v1.5.0 release notes
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Dec 27, 2006, 12:12 UTC
- Message-ID
- <200612271312.15877.jnareb@gmail.com>
- In-Reply-To
- <7v1wml8wmw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 21 quoted lines
> Jakub Narebski <jnareb@gmail.com> 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.
Show 21 quoted lines
>>> - 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