Subject: Re: [PATCH v2 3/3] sequencer: reencode to utf-8 before arrange rebase's todo list

From: Danh Doan <[email-masked]>
Date: Wed, 6 Nov 2019 17:03:22 +0700

On 2019-11-05 23:03:14 -0500, Jeff King wrote:
> >     3. You are dealing with a project originated on and migrated
> >        from a foreign SCM, and older parts of the history is stored
> >        in a non-utf-8, even though recent history is in utf-8
> > 
> > to the mix?
> 
> I would think you'd want to convert to utf-8 as you do the migration in
> that case, since you're writing new hashes anyway.

Sorry but I'm confused.
If we're migrating from foreign SCM, we could make our commit in
utf-8 (convert their commit message to utf8).
Even if we need to synchronise history between the foreign SCM in
question with git, we could use i18n.logoutputencoding for the output
comestic.

> But I think a similar
> case would just be an old Git repository, where for some reason you
> thought i18n.commitEncoding was a good idea back then (perhaps because
> you were in situation (1) then, but now you aren't).
> 
> In either case, though, I don't think it's a compelling motivation for
> optimization, if only because those old commits will be shown less and
> less (and even without modern optimizations like commit-graph, we'd
> generally avoid reencoding those old commits unless we're actually going
> to _show_ them).

I'm not sure if we're misunderstood each other.
I've only suggested to encode _new_ commit from now on in utf-8.
Reencoding old history in utf-8 is definitely not in that suggestion.

-- 
Danh