git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git-rebase is ignoring working-tree-encoding

From
ABAdrián Gimeno Balaguer <adrigibal@gmail.com>
Date
Nov 7, 2018, 04:38 UTC
Message-ID
<CADN+U_N345aMaiN4CT-_qsecw2gv=8-r+Hqq+CNz-xOx2KGYzg@mail.gmail.com>
In-Reply-To
<20181106201618.GA30158@tor.lan>
Hello Torsten,
Thanks for answering.

Answering to your question, I removed the comments with "rebase" since my reported encoding issue happens on more simpler operations (described in the PR), and the problem is not directly related to rebasing, so I considered it better in order to avoid unrelated confusions.

Let's get back to the problem. Each system has a default endianness. Also, in .gitattributes's working-tree-encoding, Git behaves differently depending on the attribute's value and the contents of the referenced entry file. When I put the value "UTF-16", then the file must have a BOM, or Git complains. Otherwise, if I put the value "UTF-16BE" or "UTF-16LE", then Git prohibites operations if file has a BOM for that main encoding (UTF-16 here), which can be relate to any endianness.

My very initial goal was, given a UTF-16LE file, to be able to view human-readable diffs whenever I make a change on it (and yes, it must be Little Endian). Plus, this file had a BOM. Now, what are the options with Git currently (consider only working-tree-encoding)? If I put working-tree-encoding=UTF-16, then I could view readable diffs and commit the file, but here is the main problem: Git looses information about what initial endianness the file had, therefore, after staging/committing it re-encodes the file from UTF-8 (as stored internally) to UTF-16 and the default system endianness. In my case it did to Big Endian, thus affecting the project's requirement. That is why I ended up writing a fixup script to change the encoding back to UTF-16LE.

On the other hand, once I set working-tree-encoding=UTF-16LE, then Git prohibited me from committing the file and even viewing human-readable diffs (the output simply tells it's a binary file). In this sense, the internal location of these errors is within the function of utf8.c I made changes to in the PR. I hope I was clearer!

Finally, Git behaviour around this is based on Unicode standards, which is why I acknowledged that my changes violated them after refering to a link which is present in the ut8.h file. El mar., 6 nov. 2018 a las 21:16, Torsten Bögershausen (<tboegi@web.de>) escribió:

Show 80 quoted lines
>
> On Mon, Nov 05, 2018 at 07:10:14PM +0100, Torsten Bögershausen wrote:
> > On Mon, Nov 05, 2018 at 05:24:39AM +0100, Adrián Gimeno Balaguer wrote:
> >
> > []
> >
> > > https://github.com/git/git/pull/550
> >
> > []
> >
> > > This is covered in the mentioned PR above. Thanks for feedback.
> >
> > Thanks for the code,
> > I will have a look (the next days)
> >
> > >
> > > --
> > > Adrián
>
> Hej Adrián,
>
> I still didn't manage to fully understand your problem.
> I tried to convert your test into my understanding,
> It can be fetched here (or copied from this message, see below)
>
> https://github.com/tboegi/git/tree/tb.181106_UTF16LE_commit
>
> The commit of an empty file seems to work for me, in the initial
> report a "rebase" was mentioned, which is not in the TC ?
>
> Is the following what you intended to test ?
>
> #!/bin/sh
> test_description='UTF-16 LE/BE file encoding using working-tree-encoding'
>
>
> . ./test-lib.sh
>
> # We specify the UTF-16LE BOM manually, to not depend on programs such as iconv.
> utf16leBOM=$(printf '\377\376')
>
> test_expect_success 'Stage empty UTF-16LE file as binary' '
>         >empty_0.txt &&
>         echo "empty_0.txt binary" >>.gitattributes &&
>         git add empty_0.txt
> '
>
>
> test_expect_success 'Stage empty file with enc=UTF.16BL' '
>         >utf16le_0.txt &&
>         echo "utf16le_0.txt text working-tree-encoding=UTF-16BE" >>.gitattributes &&
>         git add utf16le_0.txt
> '
>
>
> test_expect_success 'Create and stage UTF-16LE file with only BOM' '
>         printf "$utf16leBOM" >utf16le_1.txt &&
>         echo "utf16le_1.txt text working-tree-encoding=UTF-16" >>.gitattributes &&
>         git add utf16le_1.txt
> '
>
> test_expect_success 'Dont stage UTF-16LE file with only BOM with enc=UTF.16BE' '
>         printf "$utf16leBOM" >utf16le_2.txt &&
>         echo "utf16le_2.txt text working-tree-encoding=UTF-16BE" >>.gitattributes &&
>         test_must_fail git add utf16le_2.txt
> '
>
> test_expect_success 'commit all files' '
>         test_tick &&
>         git commit -m "Commit all 3 files"
> '
>
> test_expect_success 'All commited files have the same sha' '
>         git ls-files -s --eol >tmp1 &&
>         sed -e "s!      i/none.*!!" <tmp1 | uniq -u >actual &&
>         >expect &&
>         test_cmp expect actual
> '
>
> test_done
-- 
Adrián
Previous: Torsten BögershausenNext: Torsten Bögershausen
Message 9 of 25 in “git-rebase is ignoring working-tree-encoding”
  1. Adrián Gimeno BalaguerNov 2, 2018
  2. brian m. carlsonNov 4, 2018
  3. Adrián Gimeno BalaguerNov 4, 2018
  4. brian m. carlsonNov 4, 2018
  5. Torsten BögershausenNov 4, 2018
  6. Adrián Gimeno BalaguerNov 5, 2018
  7. Torsten BögershausenNov 5, 2018
  8. Torsten BögershausenNov 6, 2018
  9. Adrián Gimeno BalaguerNov 7, 2018
  10. Torsten BögershausenNov 8, 2018
  11. Alexandre GrigorievDec 26, 2018
  12. brian m. carlsonDec 26, 2018
  13. Alexandre GrigorievDec 27, 2018
  14. Torsten BögershausenDec 27, 2018
  15. Alexandre GrigorievDec 23, 2018
  16. 1/1 Support working-tree-encoding "UTF-16LE-BOM"tboegi@web.de, Dec 29, 2018
  17. 1/1 Support working-tree-encoding "UTF-16LE-BOM"tboegi@web.de, Jan 20, 2019
  18. Junio C HamanoJan 22, 2019
  19. 1/1 Support working-tree-encoding "UTF-16LE-BOM"tboegi@web.de, Jan 30, 2019
  20. Jason PyeronJan 30, 2019
  21. Torsten BögershausenJan 30, 2019
  22. 1/1 gitattributes.txt: fix typotboegi@web.de, Mar 6, 2019
  23. Junio C HamanoMar 7, 2019
  24. Adrián Gimeno BalaguerDec 29, 2018
  25. Philip OakleyDec 29, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.