rebase in gitbutler cause conflicts with line endings when autocrlf is set to true

[hayt]

Version

0.13.14

Operating System

Windows

Distribution Method

msi (Windows)

Describe the issue

I was trying to test gitbutler on an already existing repository where I have autocrlf true enabled because I work on windows and use the git-bash there.

When I now change a commit with the edit patch option I will get conflicts in all subsequent commits over the whole file because the line endings are different.

How to reproduce

• setup a repo without gitbutler. On windows with autocrlf set to true

• Have a file with an initial commit and some text with line breaks.

• make a new branch that is not main

• make commit 1 where you add another line with text to the beginning of the file

• make commit 2 where you add another line with text to the end of the file

• open that repo with gitbutler and edit commit 1, where you change something in the line you introduced with that commit

• commit 2 should now show up as conflict.

When I check the conflicting file with an editor that shows crlf characters, the "ours" part has crlf as line nedings, while tne ancestor and "theirs" uses LF

Expected behavior

the autocrlf setting should be respected and I should not get merge conflicts based on line endings.

Relevant log output

No response

[Byron]

Thanks a lot for posting, and the detailed instructions made it easy to reproduce. Please fine attached the test-repository (autocrlf.zip) that I used to see the conflict - it can probably just be opened in GitButler as is to see the conflict.

<<<<<<< ours
a`-changed
2
3
4
5
||||||| ancestor
a`
2
3
4
5
=======
a`

2

3

4

b

>>>>>>> theirs

Event thought there should be none.

This is probably an issue that will go away once gitoxide is used for merging, as it respects filters and thus should not try to compare CRLF with LF.

CC @Caleb-T-Owens

[Caleb-T-Owens]

@Byron I'm not sure we should ignore line endings in merges or diffs because they are significant. On some bash implementations on windows, you MUST have LF rather than CRLF or perhaps vice versa, otherwise it causes issues.

We should however ensure that the autocrlf gets observed correctly.

[Byron]

Actually, it turns out that I tested this wrongly so my merge-conflict was legit.
However, when retrying so that core.autocrlf = true in the repository configuration file was set, and a file was checked out with CRLF in the working tree and with LF in Git, I was able to reproduce the issue squarely.

Here is the repository that shows the conflict: autocrlf.zip

[Byron]

This should be fixed with the next nightly and I hope you will be able to try it out.

Please do let us know if it's not working, or anything else that comes to mind - in any case I wasn't able to reproduce the issue anymore with this new version.

[hayt]

It looks good now. Thanks for the quick fix