Thread (11 messages) 11 messages, 5 authors, 2018-07-02

Re: Use of new .gitattributes working-tree-encoding attribute across different platform types

From: Lars Schneider <hidden>
Date: 2018-07-02 14:09:39

-----Lars Schneider [off-list ref] wrote: -----
To: Jeff King <redacted>
From: Lars Schneider <redacted>
Date: 06/28/2018 18:21
Cc: "brian m. carlson" <redacted>, Steve Groeger <redacted>, git@vger.kernel.org
Subject: Re: Use of new .gitattributes working-tree-encoding attribute across different platform types

quoted
On Jun 28, 2018, at 4:34 PM, Jeff King [off-list ref] wrote:

On Thu, Jun 28, 2018 at 02:44:47AM +0000, brian m. carlson wrote:
quoted
On Wed, Jun 27, 2018 at 07:54:52AM +0000, Steve Groeger wrote:
quoted
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 [off-list ref] 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.GC7965@genre.crustytoothpaste.net/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help