Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> 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 - 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