> -----Lars Schneider <larsxschnei...@gmail.com> wrote: -----
> To: Jeff King <p...@peff.net>
> From: Lars Schneider <larsxschnei...@gmail.com>
> Date: 06/28/2018 18:21
> Cc: "brian m. carlson" <sand...@crustytoothpaste.net>, Steve Groeger
> <groe...@uk.ibm.com>, git@vger.kernel.org
> Subject: Re: Use of new .gitattributes working-tree-encoding attribute across
> different platform types
>
>
>> On Jun 28, 2018, at 4:34 PM, Jeff King <p...@peff.net> wrote:
>>
>> On Thu, Jun 28, 2018 at 02:44:47AM +0000, brian m. carlson wrote:
>>
>>> On Wed, Jun 27, 2018 at 07:54:52AM +0000, Steve Groeger wrote:
>>>> We have common code that is supposed to be usable across different
>>>> platforms and hence different file encodings. With the full support of the
>>>> working-tree-encoding in the latest version of git on all platforms, how
>>>> do we have files converted to different encodings on different platforms?
>>>> I could not find anything that would allow us to say 'if platform = z/OS
>>>> then encoding=EBCDIC else encoding=ASCII'. Is there a way this can be
>>>> done?
>>>
>>> I don't believe there is such functionality. Git doesn't have
>>> attributes that are conditional on the platform in that sort of way.
>>> You could use a smudge/clean filter and adjust the filter for the
>>> platform you're on, which might meet your needs.
>>
>> We do have prior art in the line-ending code, though. There the
>> attributes say either that a file needs a specific line-ending type
>> (which is relatively rare), or that it should follow the system type,
>> which is then set separately in the config.
>>
>> I have the impression that the working-tree-encoding stuff was made to
>> handle the first case, but not the second. It doesn't seem like an
>> outrageous thing to eventually add.
>>
>> (Though I agree that clean/smudge filters would work, and can even
>> implement the existing working-tree-encoding feature, albeit less
>> efficiently and conveniently).
>
> Thanks for the suggestion Peff!
> How about this:
>
> 1) We allow users to set the encoding "auto". Example:
>
> *.txt working-tree-encoding=auto
>
> 2) We define a new variable `core.autoencoding`. By default the value is
> UTF-8 (== no re-encoding) but user can set to any value in their Git config.
> Example:
>
> git config --global core.autoencoding UTF-16
>
> All files marked with the value "auto" will use the encoding defined in
> `core.autoencoding`.
>
> Would that work?
>
> @steve: Would that fix your problem?
On Jul 2, 2018, at 2:13 PM, Steve Groeger <groe...@uk.ibm.com> wrote:
>
> I think this proposed solution may resolve my issue.
Thanks for the confirmation!
Brian had a good argument [1] for an even more flexible system
proposed by Peff:
1) We allow users to define custom encoding mappings in their Git config.
Example:
git config --global core.encoding.myenc UTF-16
2) Users can reuse these mappings in ther .gitattributes files:
*.txt working-tree-encoding=myenc
Does this idea look good to everyone?
Thanks,
Lars
[1]
https://public-inbox.org/git/20180701175657.gc7...@genre.crustytoothpaste.net/
