Potential fix for code scanning alert no. 60: Inefficient regular expression

[Git-Hub-Chris]

Potential fix for https://github.com/Git-Hub-Chris/MicrosoftVsCode/security/code-scanning/60

To fix the problem, we need to rewrite the regular expression on line 70 to avoid ambiguous subpatterns that could be matched in multiple ways during backtracking—specifically, the .* and .*? patterns. In this context, the regular expression is used to identify and extract file paths in status/comment lines from git, which almost always use non-whitespace file names (with possible spaces but not newlines or tabs). We should make the capturing patterns more specific, such that file1 and file2 will not match the '->' separator or newline, and also will not greedily over-match white space separators.

We can thus replace .* with something like \S.*? or [^->\n]+ (excluding the '->' token or at least newline and the separator), or more conservatively, match everything up to the next separator or EOL. Commonly, file names in this context do not contain the substring ' -> '; so, we can use a negated character group or non-greedy matching up to the next separator.

Proposed change:

• Replace .*? (for file1) with a capture like [^\n]+? or perhaps more strictly [^-][^>\n]+? (but that gets awkward)
• Replace .* (for file2) within the repeated group with a similarly constrained pattern: e.g., [^\n]+?

After testing various cases, an appropriate rewrite would be:

^#\s+(modified|new file|deleted|renamed|copied|type change):\s+(?<file1>[^\n]*?)(?:\s+->\s+(?<file2>[^\n]*))*$

Or, if '->' can truly never appear in the filename, and separators are ' -> ', then:

^#\s+(modified|new file|deleted|renamed|copied|type change):\s+(?<file1>[^-][^>\n]*?)(?:\s+->\s+(?<file2>[^-][^>\n]*))*$

But to keep things simpler and retain as much previous behavior as possible, [^\n]*? is safe and avoids backtracking.

Edit line 70 in gitEditor.ts to use the updated regex.

---

Suggested fixes powered by Copilot Autofix. Review carefully before merging.