{"thread":{"id":"48788","subject":"Use of new .gitattributes working-tree-encoding attribute across different platform types","startedAt":"2018-06-27T07:55:00Z","lastAt":"2018-07-03T16:01:12Z","messageCount":12,"participants":["Steve Groeger","Torsten Bögershausen","brian m. carlson","Jeff King","Lars Schneider","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"351082","messageId":"OF5D40FE06.C18CD7CD-ON002582B9.002B7A02-002582B9.002B7A07@notes.na.collabserv.com","threadId":"48788","inReplyTo":null,"subject":"Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"Steve Groeger","fromEmail":"groeges@uk.ibm.com","sentAt":"2018-06-27T07:54:52Z","receivedAt":"2018-06-27T07:55:00Z","isPatch":false,"sender":{"key":"groeges@uk.ibm.com","avatar":null},"body":"Hi, \n\nSorry for incomplete post earlier. Here is the full post:\n\n\nIn the latest version of git a new attribute has been added, working-tree-encoding. The release notes states: \n\n'The new \"working-tree-encoding\" attribute can ask Git to convert the\n   contents to the specified encoding when checking out to the working\n   tree (and the other way around when checking in).'\n We have been using this attribute on our z/OS systems using a version of git from Rocket software to convert files to EBCDIC for quite a while now. On other platforms (Linux, AIX etc) git ignored this attribute and therefore left the files in ASCII.\n\nWe 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?\nI 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?\n \n \n  \n \nThanks\n Steve Groeger\n Java Runtimes Development\n IBM Hursley\n IBM United Kingdom Ltd\n Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129\n Fax (44) 1962 816800\n Lotus Notes: Steve Groeger/UK/IBM\n Internet: groeges@uk.ibm.com  \n   \n \nUnless stated otherwise above:\n IBM United Kingdom Limited - Registered in England and Wales with number 741598.\n Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU      \nUnless stated otherwise above:\nIBM United Kingdom Limited - Registered in England and Wales with number 741598. \nRegistered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU\n\n"},{"id":"351127","messageId":"b0039999-fe6f-eee3-5cc6-4ca638dddf79@web.de","threadId":"48788","inReplyTo":"OF5D40FE06.C18CD7CD-ON002582B9.002B7A02-002582B9.002B7A07@notes.na.collabserv.com","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2018-06-27T17:38:30Z","receivedAt":"2018-06-27T17:38:42Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 27.06.18 09:54, Steve Groeger wrote:\n> Hi, \n> \n> Sorry for incomplete post earlier. Here is the full post:\n> \n> \n> In the latest version of git a new attribute has been added, working-tree-encoding. The release notes states: \n> \n> 'The new \"working-tree-encoding\" attribute can ask Git to convert the\n>    contents to the specified encoding when checking out to the working\n>    tree (and the other way around when checking in).'\n>  We have been using this attribute on our z/OS systems using a version of git from Rocket software to convert files to EBCDIC for quite a while now. On other platforms (Linux, AIX etc) git ignored this attribute and therefore left the files in ASCII.\n> \n> 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?\n> 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?\n>  \n>  \n>   \n>  \n> Thanks\n>  Steve Groeger\n[]\n\nDid you consider to put a gitattributes file on machine level ?\n\nhttps://git-scm.com/docs/gitattributes\n\n[snipped the other places where to put gitattributes]\n...\nAttributes for all users on a system should be placed in the $(prefix)/etc/gitattributes file.\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n>  Java Runtimes Development\n>  IBM Hursley\n>  IBM United Kingdom Ltd\n>  Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129\n>  Fax (44) 1962 816800\n>  Lotus Notes: Steve Groeger/UK/IBM\n>  Internet: groeges@uk.ibm.com  \n>    \n>  \n> Unless stated otherwise above:\n>  IBM United Kingdom Limited - Registered in England and Wales with number 741598.\n>  Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU      \n> Unless stated otherwise above:\n> IBM United Kingdom Limited - Registered in England and Wales with number 741598. \n> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU\n> \n\n"},{"id":"351182","messageId":"20180628024446.GD644867@genre.crustytoothpaste.net","threadId":"48788","inReplyTo":"OF5D40FE06.C18CD7CD-ON002582B9.002B7A02-002582B9.002B7A07@notes.na.collabserv.com","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-06-28T02:44:47Z","receivedAt":"2018-06-28T02:44:56Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Wed, Jun 27, 2018 at 07:54:52AM +0000, Steve Groeger wrote:\n> 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?\n> 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?\n\nI don't believe there is such functionality.  Git doesn't have\nattributes that are conditional on the platform in that sort of way.\nYou could use a smudge/clean filter and adjust the filter for the\nplatform you're on, which might meet your needs.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"351223","messageId":"20180628143405.GA16657@sigill.intra.peff.net","threadId":"48788","inReplyTo":"20180628024446.GD644867@genre.crustytoothpaste.net","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-06-28T14:34:06Z","receivedAt":"2018-06-28T14:34:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 28, 2018 at 02:44:47AM +0000, brian m. carlson wrote:\n\n> On Wed, Jun 27, 2018 at 07:54:52AM +0000, Steve Groeger wrote:\n> > 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?\n> > 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?\n> \n> I don't believe there is such functionality.  Git doesn't have\n> attributes that are conditional on the platform in that sort of way.\n> You could use a smudge/clean filter and adjust the filter for the\n> platform you're on, which might meet your needs.\n\nWe do have prior art in the line-ending code, though. There the\nattributes say either that a file needs a specific line-ending type\n(which is relatively rare), or that it should follow the system type,\nwhich is then set separately in the config.\n\nI have the impression that the working-tree-encoding stuff was made to\nhandle the first case, but not the second. It doesn't seem like an\noutrageous thing to eventually add.\n\n(Though I agree that clean/smudge filters would work, and can even\nimplement the existing working-tree-encoding feature, albeit less\nefficiently and conveniently).\n\n-Peff\n"},{"id":"351242","messageId":"4E8CDDC9-2957-401F-9BBE-93276C026848@gmail.com","threadId":"48788","inReplyTo":"20180628143405.GA16657@sigill.intra.peff.net","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2018-06-28T17:21:18Z","receivedAt":"2018-06-28T17:21:25Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n\n> On Jun 28, 2018, at 4:34 PM, Jeff King <peff@peff.net> wrote:\n> \n> On Thu, Jun 28, 2018 at 02:44:47AM +0000, brian m. carlson wrote:\n> \n>> On Wed, Jun 27, 2018 at 07:54:52AM +0000, Steve Groeger wrote:\n>>> 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?\n>>> 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?\n>> \n>> I don't believe there is such functionality.  Git doesn't have\n>> attributes that are conditional on the platform in that sort of way.\n>> You could use a smudge/clean filter and adjust the filter for the\n>> platform you're on, which might meet your needs.\n> \n> We do have prior art in the line-ending code, though. There the\n> attributes say either that a file needs a specific line-ending type\n> (which is relatively rare), or that it should follow the system type,\n> which is then set separately in the config.\n> \n> I have the impression that the working-tree-encoding stuff was made to\n> handle the first case, but not the second. It doesn't seem like an\n> outrageous thing to eventually add.\n> \n> (Though I agree that clean/smudge filters would work, and can even\n> implement the existing working-tree-encoding feature, albeit less\n> efficiently and conveniently).\n\nThanks for the suggestion Peff! \nHow about this:\n\n1) We allow users to set the encoding \"auto\". Example:\n\n\t*.txt working-tree-encoding=auto\n\n2) We define a new variable `core.autoencoding`. By default the value is \nUTF-8 (== no re-encoding) but user can set to any value in their Git config. \nExample:\n\n    git config --global core.autoencoding UTF-16\n\nAll files marked with the value \"auto\" will use the encoding defined in\n`core.autoencoding`.\n\nWould that work?\n\n@steve: Would that fix your problem?\n\n- Lars"},{"id":"351243","messageId":"20180628172707.GA31766@sigill.intra.peff.net","threadId":"48788","inReplyTo":"4E8CDDC9-2957-401F-9BBE-93276C026848@gmail.com","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-06-28T17:27:07Z","receivedAt":"2018-06-28T17:27:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 28, 2018 at 07:21:18PM +0200, Lars Schneider wrote:\n\n> How about this:\n> \n> 1) We allow users to set the encoding \"auto\". Example:\n> \n> \t*.txt working-tree-encoding=auto\n> \n> 2) We define a new variable `core.autoencoding`. By default the value is \n> UTF-8 (== no re-encoding) but user can set to any value in their Git config. \n> Example:\n> \n>     git config --global core.autoencoding UTF-16\n> \n> All files marked with the value \"auto\" will use the encoding defined in\n> `core.autoencoding`.\n> \n> Would that work?\n\nYeah, that was along the lines that I was thinking. I wonder if anybody\nwould ever need two such auto-encodings, though. Probably not. But\nanother way to think about it would be to allow something like:\n\n  working-tree-encoding=foo\n\nand then in your config \"foo\" to map to some encoding.\n\nBut that may be over-engineering, I dunno. utf8 has always been enough\nfor me. :)\n\n-Peff\n"},{"id":"351478","messageId":"20180701175657.GC7965@genre.crustytoothpaste.net","threadId":"48788","inReplyTo":"20180628172707.GA31766@sigill.intra.peff.net","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-07-01T17:56:58Z","receivedAt":"2018-07-01T17:57:18Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Thu, Jun 28, 2018 at 01:27:07PM -0400, Jeff King wrote:\n> Yeah, that was along the lines that I was thinking. I wonder if anybody\n> would ever need two such auto-encodings, though. Probably not. But\n> another way to think about it would be to allow something like:\n> \n>   working-tree-encoding=foo\n> \n> and then in your config \"foo\" to map to some encoding.\n> \n> But that may be over-engineering, I dunno. utf8 has always been enough\n> for me. :)\n\nI had a thought the other day about why this solution might be valuable.\nDifferent platforms encode different values for iconv character sets.\nSo, for example, one may have platforms supporting some disjoint sets of\nthe following:\n\n* LATIN-1\n* LATIN1\n* ISO8859-1\n* ISO-8859-1\n* ISO_8859-1\n* ISO_8859-1:1987\n* some lowercase variants of these\n\nTherefore, specifying a working-tree-encoding value that works across a\nwide variety of system may be non-trivial.  This is less of a problem\nwith UTF-8, but having the ability to pick an encoding and remap it to a\nsupported value may be useful nevertheless.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"351524","messageId":"OFAD36A6D5.F36D27E7-ON002582BE.0043296C-002582BE.0043297F@notes.na.collabserv.com","threadId":"48788","inReplyTo":"4E8CDDC9-2957-401F-9BBE-93276C026848@gmail.com","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"Steve Groeger","fromEmail":"groeges@uk.ibm.com","sentAt":"2018-07-02T12:13:35Z","receivedAt":"2018-07-02T12:13:46Z","isPatch":false,"sender":{"key":"groeges@uk.ibm.com","avatar":null},"body":"Lars, \n\nI think this proposed solution may resolve my issue.\n \n \n  \n \nThanks\n Steve Groeger\n Java Runtimes Development\n IBM Hursley\n IBM United Kingdom Ltd\n Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129\n Fax (44) 1962 816800\n Lotus Notes: Steve Groeger/UK/IBM\n Internet: groeges@uk.ibm.com  \n   \n \nUnless stated otherwise above:\n IBM United Kingdom Limited - Registered in England and Wales with number 741598.\n Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU      \n\n-----Lars Schneider <larsxschneider@gmail.com> wrote: -----\nTo: Jeff King <peff@peff.net>\nFrom: Lars Schneider <larsxschneider@gmail.com>\nDate: 06/28/2018 18:21\nCc: \"brian m. carlson\" <sandals@crustytoothpaste.net>, Steve Groeger <GROEGES@uk.ibm.com>, git@vger.kernel.org\nSubject: Re: Use of new .gitattributes working-tree-encoding attribute across different platform types\n\n\n> On Jun 28, 2018, at 4:34 PM, Jeff King <peff@peff.net> wrote:\n> \n> On Thu, Jun 28, 2018 at 02:44:47AM +0000, brian m. carlson wrote:\n> \n>> On Wed, Jun 27, 2018 at 07:54:52AM +0000, Steve Groeger wrote:\n>>> 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?\n>>> 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?\n>> \n>> I don't believe there is such functionality.  Git doesn't have\n>> attributes that are conditional on the platform in that sort of way.\n>> You could use a smudge/clean filter and adjust the filter for the\n>> platform you're on, which might meet your needs.\n> \n> We do have prior art in the line-ending code, though. There the\n> attributes say either that a file needs a specific line-ending type\n> (which is relatively rare), or that it should follow the system type,\n> which is then set separately in the config.\n> \n> I have the impression that the working-tree-encoding stuff was made to\n> handle the first case, but not the second. It doesn't seem like an\n> outrageous thing to eventually add.\n> \n> (Though I agree that clean/smudge filters would work, and can even\n> implement the existing working-tree-encoding feature, albeit less\n> efficiently and conveniently).\n\nThanks for the suggestion Peff! \nHow about this:\n\n1) We allow users to set the encoding \"auto\". Example:\n\n\t*.txt working-tree-encoding=auto\n\n2) We define a new variable `core.autoencoding`. By default the value is \nUTF-8 (== no re-encoding) but user can set to any value in their Git config. \nExample:\n\n    git config --global core.autoencoding UTF-16\n\nAll files marked with the value \"auto\" will use the encoding defined in\n`core.autoencoding`.\n\nWould that work?\n\n@steve: Would that fix your problem?\n\n- Lars\nUnless stated otherwise above:\nIBM United Kingdom Limited - Registered in England and Wales with number 741598. \nRegistered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU\n\n"},{"id":"351529","messageId":"4621C69D-B837-43ED-8570-462D4CF2BBA0@gmail.com","threadId":"48788","inReplyTo":"OFAD36A6D5.F36D27E7-ON002582BE.0043296C-002582BE.0043297F@notes.na.collabserv.com","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2018-07-02T14:09:32Z","receivedAt":"2018-07-02T14:09:39Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"> -----Lars Schneider <larsxschneider@gmail.com> wrote: -----\n> To: Jeff King <peff@peff.net>\n> From: Lars Schneider <larsxschneider@gmail.com>\n> Date: 06/28/2018 18:21\n> Cc: \"brian m. carlson\" <sandals@crustytoothpaste.net>, Steve Groeger <GROEGES@uk.ibm.com>, git@vger.kernel.org\n> Subject: Re: Use of new .gitattributes working-tree-encoding attribute across different platform types\n> \n> \n>> On Jun 28, 2018, at 4:34 PM, Jeff King <peff@peff.net> wrote:\n>> \n>> On Thu, Jun 28, 2018 at 02:44:47AM +0000, brian m. carlson wrote:\n>> \n>>> On Wed, Jun 27, 2018 at 07:54:52AM +0000, Steve Groeger wrote:\n>>>> 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?\n>>>> 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?\n>>> \n>>> I don't believe there is such functionality.  Git doesn't have\n>>> attributes that are conditional on the platform in that sort of way.\n>>> You could use a smudge/clean filter and adjust the filter for the\n>>> platform you're on, which might meet your needs.\n>> \n>> We do have prior art in the line-ending code, though. There the\n>> attributes say either that a file needs a specific line-ending type\n>> (which is relatively rare), or that it should follow the system type,\n>> which is then set separately in the config.\n>> \n>> I have the impression that the working-tree-encoding stuff was made to\n>> handle the first case, but not the second. It doesn't seem like an\n>> outrageous thing to eventually add.\n>> \n>> (Though I agree that clean/smudge filters would work, and can even\n>> implement the existing working-tree-encoding feature, albeit less\n>> efficiently and conveniently).\n> \n> Thanks for the suggestion Peff! \n> How about this:\n> \n> 1) We allow users to set the encoding \"auto\". Example:\n> \n> \t*.txt working-tree-encoding=auto\n> \n> 2) We define a new variable `core.autoencoding`. By default the value is \n> UTF-8 (== no re-encoding) but user can set to any value in their Git config. \n> Example:\n> \n>    git config --global core.autoencoding UTF-16\n> \n> All files marked with the value \"auto\" will use the encoding defined in\n> `core.autoencoding`.\n> \n> Would that work?\n> \n> @steve: Would that fix your problem?\n\n\nOn Jul 2, 2018, at 2:13 PM, Steve Groeger <GROEGES@uk.ibm.com> wrote:\n> \n> I think this proposed solution may resolve my issue.\n\nThanks for the confirmation!\n\nBrian had a good argument [1] for an even more flexible system\nproposed by Peff:\n\n\n1) We allow users to define custom encoding mappings in their Git config. \nExample:\n\n    git config --global core.encoding.myenc UTF-16\n\n\n2) Users can reuse these mappings in ther .gitattributes files:\n\n    *.txt working-tree-encoding=myenc\n\n\nDoes this idea look good to everyone?\n\nThanks,\nLars\n\n\n[1] https://public-inbox.org/git/20180701175657.GC7965@genre.crustytoothpaste.net/\n"},{"id":"351537","messageId":"20180702181742.GA12208@sigill.intra.peff.net","threadId":"48788","inReplyTo":"20180701175657.GC7965@genre.crustytoothpaste.net","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-07-02T18:17:42Z","receivedAt":"2018-07-02T18:17:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jul 01, 2018 at 05:56:58PM +0000, brian m. carlson wrote:\n\n> On Thu, Jun 28, 2018 at 01:27:07PM -0400, Jeff King wrote:\n> > Yeah, that was along the lines that I was thinking. I wonder if anybody\n> > would ever need two such auto-encodings, though. Probably not. But\n> > another way to think about it would be to allow something like:\n> > \n> >   working-tree-encoding=foo\n> > \n> > and then in your config \"foo\" to map to some encoding.\n> > \n> > But that may be over-engineering, I dunno. utf8 has always been enough\n> > for me. :)\n> \n> I had a thought the other day about why this solution might be valuable.\n> Different platforms encode different values for iconv character sets.\n> So, for example, one may have platforms supporting some disjoint sets of\n> the following:\n> \n> * LATIN-1\n> * LATIN1\n> * ISO8859-1\n> * ISO-8859-1\n> * ISO_8859-1\n> * ISO_8859-1:1987\n> * some lowercase variants of these\n> \n> Therefore, specifying a working-tree-encoding value that works across a\n> wide variety of system may be non-trivial.  This is less of a problem\n> with UTF-8, but having the ability to pick an encoding and remap it to a\n> supported value may be useful nevertheless.\n\nOne thing I almost did in the example I gave above was to literally call\nthe encoding name by a \"real\" one. I.e.:\n\n  echo '*.txt working-tree-encoding=iso-8859-1' >.gitattributes\n  git config encoding.iso-8859-1.replace latin1\n\nor something. But I wondered if it was a little crazy as a practice,\nsince mapping \"iso-8859-1\" to \"utf-8\" is probably going to lead to\nheadaches.\n\nBut your example above of semantically equivalent variants with\ndifferent spellings would be a good use of that trick.\n\nIt also makes me wonder if there's another layer of indirection\nsomewhere in the iconv machinery we could be taking advantage of to\naccomplish the same thing.  Probably not conveniently or portably, I\nguess.\n\n-Peff\n"},{"id":"351538","messageId":"20180702182016.GB12208@sigill.intra.peff.net","threadId":"48788","inReplyTo":"4621C69D-B837-43ED-8570-462D4CF2BBA0@gmail.com","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-07-02T18:20:16Z","receivedAt":"2018-07-02T18:20:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 02, 2018 at 04:09:32PM +0200, Lars Schneider wrote:\n\n> Brian had a good argument [1] for an even more flexible system\n> proposed by Peff:\n> \n> \n> 1) We allow users to define custom encoding mappings in their Git config. \n> Example:\n> \n>     git config --global core.encoding.myenc UTF-16\n\nI think this should be encoding.myenc.something. In Git's config format,\nonly the subsection names (the middle of a three-dot name) are\nunconstrained. So even if encoding.myenc only ever has one key\n(\"replace\" or \"useInstead\" or whatever you want to call it), there's\nvalue in organizing the namespace that way.\n\nAnd as a bonus, it leaves room for extending the feature later if we do\nneed more keys.\n\n-Peff\n"},{"id":"351627","messageId":"xmqqsh50s3zy.fsf@gitster-ct.c.googlers.com","threadId":"48788","inReplyTo":"20180702181742.GA12208@sigill.intra.peff.net","subject":"Re: Use of new .gitattributes working-tree-encoding attribute across different platform types","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-07-03T16:01:05Z","receivedAt":"2018-07-03T16:01:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> One thing I almost did in the example I gave above was to literally call\n> the encoding name by a \"real\" one. I.e.:\n>\n>   echo '*.txt working-tree-encoding=iso-8859-1' >.gitattributes\n>   git config encoding.iso-8859-1.replace latin1\n>\n> or something. But I wondered if it was a little crazy as a practice,\n> since mapping \"iso-8859-1\" to \"utf-8\" is probably going to lead to\n> headaches.\n>\n> But your example above of semantically equivalent variants with\n> different spellings would be a good use of that trick.\n\nYeah, I think the above looks quite sensible.\n"}]}