From: Johannes Sixt <j6t@kdbg.org>
Date: Tue, 12 Dec 2017 07:15:08 GMT
Subject: Re: [PATCH v1] convert: add support for 'encoding' attribute
Message-ID: <48ebcb7a-2a7f-e790-2613-a1f3e3dc41f9@kdbg.org>
In-Reply-To: <xmqqzi6o3go9.fsf@gitster.mtv.corp.google.com>

Am 12.12.2017 um 01:59 schrieb Junio C Hamano:
> Stepping back a bit, what does this thing do you are introducing?
> And what does the other thing do that J6t is using, that would get
> confused with this new one?
> 
> What does the other one do?  "Declare that the contents of this path
> is in this encoding"?  As opposed to the new one, which tells Git to
> "run iconv from and to this encoding when checking out and checking
> in"?
> 
> If so, any phrase that depends heavily on the word "encode" would
> not help differenciating the two uses.  The phrase needs to be
> something that contrasts the new one, which actively modifies things
> (what is on the filesystem is not what is stored in the object
> store), with the old one, which does not (passed as a declaration to
> a viewer what encoding the contents already use and does not change
> anything).

Well explained!

> ...  perhaps "smudge-encoding" would work (we declare that the
> result of smudge operations are left in this encoding, so the
> opposite operation "clean" will do the reverse---and we say this
> without explicitly saying that the other end of the conversion is
> always UTF-8)?  Or "checkout-encoding" (the same explanation; we do
> not say the opposite operation "checkin/add" will do the reverse).

I would favor "checkout-encoding" over "smudge-encoding" only because 
"checkout" is better known than "smudge", I would think. I do not have 
better suggestions.

-- Hannes