Line ending normalization has occurred - PRs may have merge conflicts

[seanbudd]

We have just normalized the line endings for the entire repository to LF: #12387

This may cause merge conflicts with existing PRs.

Please handle conflicts as follows:

git checkout branchWithConflicts
# Merge master up until the normalization, handle any merge conflicts from previous code
git merge 03364662e
# Merge the line endings normalization PR, take your own unnormalized changes for now
git merge 8fb8ffcaba -X ours
# Normalize changes
git add --renormalize .
git commit -m "renormalize files"
# Merge any further changes from master, handle any merge conflicts from newer code
git merge origin/master
# Confirm diffs are as expected
git diff origin/branchWithConflicts..branchWithConflicts --ignore-cr-at-eol
git diff origin/master..branchWithConflicts --ignore-cr-at-eol
git push

Files can be checked out locally using CRLF if needed for Windows development using git.

[CyrilleB79]

Hi @seanbudd

I have merged to the commit just before the normalization to isolate future merges from this one:
git merge 9ea256659~1

When I do:

# Merge master up until the normalization, handle any merge conflicts from previous code
git merge 9ea256659

and then:
git status
I get the following file in the changes not staged for commit (I have not modified it myself):
modified: projectDocs/dev/codingStandards.md

And then when I do:

# Merge the line endings normalization PR, take your own unnormalized changes for now
git merge 8fb8ffcaba -X ours

I logically get the following message:

error: Your local changes to the following files would be overwritten by merge:
        projectDocs/dev/codingStandards.md
Please commit your changes or stash them before you merge.
Aborting

I can probably ignore the changes in projectDocs/dev/codingStandards.md (there are only end-of-line CR diffs), and then ensure that this file has the correct line ending. But I'd like you to provide more systematic steps that can be applied to any branch and that can be useful for anyone.

Thanks

Cheers,

Cyrille

[CyrilleB79]

@nvdaes thank you for replying.

I wonder, have you faced some specific issues not described here? E.g. having more files than needed to merge.

I can see in #16728 that you have merged commit 9ea2566 on June 27, 2024. Thus it seems that you have used the steps provided by @seanbudd before @seanbudd has edited the steps as described in #16761 (reply in thread). Is it correct?

If yes, @seanbudd it's not clear to me what should be done, since I have had issues both with the steps befor you modified them and after...

For now, for the branch of PR #16825, I have just manually reported the changes in a new branch. But having a clean merge process would be better since I have other pending branches / PRs, and I am not the only one.
Thanks;

[nvdaes]

@CyrilleB79 , I followed the steps provided by Sean before he edited them, i.e., the steps of the first comment by Sean. Then I merged origin/master as approrpriate. You may want to see the log of diffs made in PR #16728

[mltony]

@CyrilleB79, FWIW, I managed to merge my PR in WSL. For more info see my comment in #16591.

[CyrilleB79]

@nvdaes what is your CrLf config?
git config core.autocrlf

What does it return?

[nvdaes]

@CyrilleB79 , it returns true. Ichanged this parameter recently, after line ending normalization in NVDA when working in #16728

[XLTechie]

@CyrilleB79, I successfully used a slight variant of @seanbudd's revised steps, to update PR #16369. My variant, was that I tagged the commits he referenced, as "prenormal" and "normalize", to make doing this again easier. "git config core.autocrlf" returns nothing. The only problem I seem to have right now, is that I have an untracked file showing up in status, of "include/microsoft-ui-uiautomation/". That seems harmless for this PR, so I haven't fixed it.