fix: Make Git conflict markers check more precise

[yermulnik]

The #6113 introduced new Git merge conflicts linter check, that is error prone in some conditions (see screenshot).

This PR adjusts this check to be more precise and exact in a way that all three markers should be found to identify check as failed. Additionally improve Git merge conflict markers matchers.

Repro:

> grep -E '^(<<<<<<<|=======|>>>>>>>)' README.md
==========================================================
=============   MegaLinter, by OX.security   =============
=========  https://ox.security?ref=megalinter  ===========
==========================================================

Replaces #6374

Readiness checklist

In order to have this pull request merged, complete the following tasks.

Pull request author tasks

• I checked that all workflows return a success.
• I included all the needed documentation for this change.
• I provided the necessary tests.
• I squashed all the commits into a single commit.
• I followed the
  Conventional Commit v1.0.0 spec.
• I wrote the necessary upgrade instructions in the
  upgrade guide.
• If this pull request is about and existing issue, I added the
  Fix #ISSUE_NUMBER or Close #ISSUE_NUMBER text to the description of
  the pull request.

Super-linter maintainer tasks

• Label as breaking if this change breaks compatibility with the previous
  released version.
• Label as either: automation, bug, documentation, enhancement,
  infrastructure.
• Add the pull request to a milestone, eventually creating one, that matches
  with the version that release-please proposes in the
  preview-release-notes CI job.

[yermulnik]

@ferrarimarco I noticed the tick was added for breaking change item in previous PR:

I believe this PR doesn't introduce breaking change for the previous released version as it only rectifies false positive from the previous released version (and improves overall capability of checking for Git conflict markers).

[ferrarimarco]

@ferrarimarco I noticed the tick was added for breaking change item in previous PR

That's for maintainers to state that they checked the PR and deemed that as non-breaking, in this case.

[yermulnik]

Checks failure isn't relevant: https://github.com/super-linter/super-linter/actions/runs/11959522598/job/33342347913?pr=6379

[yermulnik]

Checks failure isn't relevant: super-linter/super-linter/actions/runs/11959522598/job/33342347913?pr=6379

@ferrarimarco Should I do something about this failure?

[ferrarimarco]

super-linter/super-linter/actions/runs/11959522598/job/33342347913?pr=6379

Not really. We just need to wait for a dependency update.

Thanks!

[yermulnik]

super-linter/super-linter/actions/runs/11959522598/job/33342347913?pr=6379

Not really. We just need to wait for a dependency update.

Gotcha. Thanks. Please ping me if there's anything I need or can do about this PR.

[yermulnik]

Not really. We just need to wait for a dependency update.

npm-audit: @yarnpkg/core -> @yarnpkg/shell -> Depends on vulnerable versions of cross-spawn

Looks like either of these two should bring in an update once new version of @yarnpkg/core is released:

• chore(deps): update cross-spawn to v7.0.6 yarnpkg/berry#6605
• chore: unlock cross-spawn range yarnpkg/berry#6606

[yermulnik]

@ferrarimarco The new version of @yarnpkg/core has been released. Could you please re-run failed workflows?

[ferrarimarco]

@yarnpkg/core is not a direct dependency:

# npm audit report

cross-spawn  7.0.0 - 7.0.4
Severity: high
Regular Expression Denial of Service (ReDoS) in cross-spawn - https://github.com/advisories/GHSA-3xgq-45jj-v275
fix available via `npm audit fix --force`
Will install [email protected], which is a breaking change
node_modules/cross-spawn
  @yarnpkg/core  <=4.1.5
  Depends on vulnerable versions of cross-spawn
  node_modules/@yarnpkg/core
    renovate  0.0.0-semantic-release || 22.22.0 - 22.22.2 || >=22.23.0
    Depends on vulnerable versions of @yarnpkg/core
    node_modules/renovate

We'd need to wait for renovate to release a new version that either updates @yarnpkg/core, or widens the version requirements for that dependency, instead of requiring a fixed version (4.1.4 at the time of writing this).

[yermulnik]

Ah, I see. Tedious =)
So I can see it's on their Dependency Dashboard already (pending status checks (whatever that means)). Wondering if it can be expedited 🤔

[echoix]

I still couldn't update my repo to use 7.2.0, as it fails on patch files (diffs) we hold to apply on an external code. I don't see a way to configure that "linter". How would you suggest to handle patch files?

[yermulnik]

I still couldn't update my repo to use 7.2.0, as it fails on patch files (diffs) we hold to apply on an external code. I don't see a way to configure that "linter". How would you suggest to handle patch files?

Out of interest: how your patch files content looks like?
To the best of my knowledge they don't contain merge conflict markers usually.

[echoix]

I still couldn't update my repo to use 7.2.0, as it fails on patch files (diffs) we hold to apply on an external code. I don't see a way to configure that "linter". How would you suggest to handle patch files?

Out of interest: how your patch files content looks like?

To the best of my knowledge they don't contain merge conflict markers usually.

The PR: OSGeo/grass-addons#1246
The run: https://github.com/OSGeo/grass-addons/actions/runs/11895745562/job/33146047065
The affected files:

• https://github.com/OSGeo/grass-addons/blob/fae26d4dd0926e3ca29521ac0e8fec622c147fd7/src/gui/wxpython/wx.wms/core.diff (false positive)
• A README.txt file, that is not a markdown file since it was older (from subversion), I think it complains about lines made of equal signs; this PR should be fixing it I think https://github.com/OSGeo/grass-addons/blob/fae26d4dd0926e3ca29521ac0e8fec622c147fd7/src/raster/r.green/README.txt
• This file has comment blocks that has equal lines, so this PR should fix this too: https://github.com/OSGeo/grass-addons/blob/fae26d4dd0926e3ca29521ac0e8fec622c147fd7/src/raster/r.vol.dem/chull.c
• This file I'm not sure if it is good or not, I don't understand the log output of it applied to this or not: https://github.com/OSGeo/grass-addons/blob/fae26d4dd0926e3ca29521ac0e8fec622c147fd7/src/gui/wxpython/wx.wms/Makefile.diff This patch was from 2011 (before it was on github)

I didn't go and read how this check is implemented here, I understand that it is made in-house, but how does it compare to a similar check from pre-commit hooks? Do they have the same problem? https://github.com/pre-commit/pre-commit-hooks?tab=readme-ov-file#check-merge-conflict

[yermulnik]

Out of interest: how your patch files content looks like?
To the best of my knowledge they don't contain merge conflict markers usually.

The affected files:

As of look of it, false positives for all those files should be resolved by this PR once it's merged into super-linter and released as v7.2.1

but how does it compare to a similar check from pre-commit hooks? Do they have the same problem? pre-commit/pre-commit-hooks#check-merge-conflict

Do they have the same problem: yes and no. They use a more stricter check than what this repo has in main branch. Though still might fall error prone in some conditions as they check merge conflict markers separately (whilst these markers have to be inspected all at once — and this is what I attempted to implement with this PR).
Fingers crossed it won't take long for v7.2.1 to get released as it also should bring other fixes and improvements.

UPD: that check from pre-commit has a feature to allow transitive status of being through the merge process — I'm not sure this is worth of being implemented in super-linter at this moment as allowing such status needs to be considered by super-linter devs (and I'm not among them 🤷🏻)