Lars,
I think this proposed solution may resolve my issue.
Thanks
Steve Groeger
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges@xxxxxxxxxx
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-----Lars Schneider <larsxschneider@xxxxxxxxx> wrote: -----
To: Jeff King <peff@xxxxxxxx>
From: Lars Schneider <larsxschneider@xxxxxxxxx>
Date: 06/28/2018 18:21
Cc: "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx>, Steve Groeger <GROEGES@xxxxxxxxxx>, git@xxxxxxxxxxxxxxx
Subject: Re: Use of new .gitattributes working-tree-encoding attribute across different platform types
> On Jun 28, 2018, at 4:34 PM, Jeff King <peff@xxxxxxxx> 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?
- Lars
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
