Re: [PATCH v1] convert: add support for 'encoding' attribute
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Dec 12, 2017, 07:15 UTC
- 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:
Show 16 quoted lines
> 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!
Show 6 quoted lines
> ... 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