You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If a project has conflict-marker-size set to a non-standard value (say 15), Lazygit ignores it, and continues to look for the markers of the default size.
if there are conflicts of size 7 but not 15, the file is incorrectly marked as unmerged by Lazygit, preventing git rebase/merge --continue
if there are conflicts of size 15 but not 7, the conflicts are automatically skipped, leading to weird stuff in the following steps
To Reproduce
Steps to reproduce the behavior:
Set conflict-marker-size in e.g. ~/.gitattributes:
Create a file with standard-sized conflict markers:
pubfnmain(){let a = "\<<<<<<< LEFTleft||||||| BASEbase=======right>>>>>>> RIGHT";}
Create an unrelated conflict, e.g. by creating two branches where one renames a to b, and the other -- to c
Try to merge the two branches
The preview window will highlight the not-actually-a-conflict (the part with conflict markers of size 7), while ignoring the actual conflict that occured
Expected behavior
The actual conflict is highlighted, and the other one isn't.
Additional context
The default conflict marker size of 7 (<<<<<<<) has become a de-facto standard, and Lazygit expects it as well. But the ability to change it is still very much present, and helpful for projects that provide conflict-related functionality and e.g. have tests containing conflict examples. The latter is the case for Mergiraf, a custom Git merge driver we've been working on.
As for a possible fix:
We had this issue in Mergiraf as well (https://codeberg.org/mergiraf/mergiraf/pulls/136). But being a merge driver, we get the value passed by Git when invoked, so obtaining the value was relatively easy. I'm not sure whether Lazygit can do something similar, but another option would be to just use git check-attr like this:
Describe the bug
If a project has
conflict-marker-size
set to a non-standard value (say 15), Lazygit ignores it, and continues to look for the markers of the default size.git rebase/merge --continue
To Reproduce
Steps to reproduce the behavior:
conflict-marker-size
in e.g.~/.gitattributes
:echo `conflict-marker-size=15` >> ~/.gitattributes
a
tob
, and the other -- toc
Expected behavior
The actual conflict is highlighted, and the other one isn't.
Version info:
Additional context
The default conflict marker size of 7 (
<<<<<<<
) has become a de-facto standard, and Lazygit expects it as well. But the ability to change it is still very much present, and helpful for projects that provide conflict-related functionality and e.g. have tests containing conflict examples. The latter is the case for Mergiraf, a custom Git merge driver we've been working on.As for a possible fix:
We had this issue in Mergiraf as well (https://codeberg.org/mergiraf/mergiraf/pulls/136). But being a merge driver, we get the value passed by Git when invoked, so obtaining the value was relatively easy. I'm not sure whether Lazygit can do something similar, but another option would be to just use
git check-attr
like this:git check-attr conflict-marker-size <file_name>
After that, one could change
lazygit/pkg/gui/mergeconflicts/find_conflicts.go
Line 61 in 19ac926
The text was updated successfully, but these errors were encountered: