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

Files with \r\n\n line endings can result in needing to renormalize twice, after deleting checked out file and restoring from repo

From
PBPhilip, Bevan <bevan.philip@softwareag.com>
Date
May 31, 2022, 14:24 UTC
Message-ID
<AM0PR02MB56357CC96B702244F3271014E8DC9@AM0PR02MB5635.eurprd02.prod.outlook.com>
Hello all,
I've experienced an odd bug/limitation with `git add --renormalize`, requiring me to run the command twice on a specific file. Here is a bug report.
What did you do before the bug happened? (Steps to reproduce your issue)

#!/bin/bash -x printf "Test\\r\\r\\nTest Another Line\\r\\r\\nFinal Line\\r\\r\\n\\r\\r\\n" > git.bdf printf "* text=auto\\n*.bdf text" > .gitattributes mkdir test1 cd test1 git init cp ../git.bdf . git add . git status git commit -m "Add file git.bdf" cp ../.gitattributes . git add .gitattributes git add --renormalize . git status git commit -m "Renormalize git.bdf" git add --renormalize . git status rm git.bdf git restore . git add --renormalize . git status

What did you expect to happen? (Expected behavior) Only needing to renormalize the file once.

What happened instead? (Actual behavior) Renormalize the file once, then renormalize again after deleting the file that is checked out on disk and restoring it from the object stored within the Git repo.

What's different between what you expected and what actually happened? Needed to run the renormalize step again, after deleting the file checked out on disk and restoring the file from the object stored within the Git repo.

Anything else you want to add: This only occurs for files with \r\r\n line endings (and possibly also ending the file with \r\r\n\r\n)

The file is in three states:
- Initial state: \r\r\n line endings within Git object
- Initial renormalization state: \r\n line endings within Git object
- Second renormalization state: \n line endings within Git object

Happens on both Windows and Linux (replicated on a fresh install of Git for Windows within Windows Sandbox). Additionally, tested with `next` trunk on Linux. System info is for a Windows build where it does happen.

Directory, and file names should be irrelevant.
We encountered this naturally, with some files within a SVN repo we're migrating.

[System Info] git version: git version 2.36.1.windows.1 cpu: x86_64 built from commit: e2ff68a2d1426758c78d023f863bfa1e03cbc768 sizeof-long: 4 sizeof-size_t: 8 shell-path: /bin/sh feature: fsmonitor--daemon uname: Windows 10.0 19043 compiler info: gnuc: 11.3 libc info: no libc information available $SHELL (typically, interactive shell): <unset>

Thanks, Bevan This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it. Software AG (UK) Limited Registered in England & Wales 1310740 - http://www.softwareag.com/uk

Next: Philip Oakley
Message 1 of 5 in “Files with \r\n\n line endings can result in needing to renormalize twice, after deleting checked out file and restoring from repo”
  1. Philip, BevanMay 31, 2022
  2. Philip OakleyMay 31, 2022
  3. Philip, BevanJun 1, 2022
  4. Philip OakleyJun 3, 2022
  5. Philip OakleyJun 5, 2022

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.