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

From: Danh Doan <congdanhqx@gmail.com>
Date: Nov 6, 2019, 10:03 UTC
Message-ID: <20191106100322.GC6351@danh.dev>
In-Reply-To: <20191106040314.GA4307@sigill.intra.peff.net>

On 2019-11-05 23:03:14 -0500, Jeff King wrote:

Show 8 quoted lines

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

Show 10 quoted lines

> 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