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

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano wrote:
> 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.

>>>  - 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