getGitConflictCount() normalizes whitespace in unmerged filenames. Two distinct conflicted files named a b.txt and a b.txt are counted as one, so the GitConflicts widget displays ⚠1 instead of ⚠2.
Reproduced on ccstatusline main 3b602348afbbe082eb919b576b55926bbf8d19d6, macOS, Bun 1.3.14, using an isolated real Git index with stages 1, 2 and 3 for each pathname. git ls-files --unmerged returns six stage records for two paths. Calling the production getGitConflictCount() and rendering the production widget returns {count: 1, rendered: "⚠1"}; expected {count: 2, rendered: "⚠2"}. A single-file control passes.
The parser in src/utils/git.ts splits each record on /\s+/ and rejoins its pathname with one space, collapsing the two filenames. Quoted filenames containing tabs or newlines can also produce incorrect counts. Git's documented ls-files -z output preserves pathnames verbatim and terminates records with NUL, which would permit exact pathname deduplication across stages.
I checked the current open PR inventory and the overlapping #631/#632 changes; those address subprocess/cache behavior and leave this parser unchanged. No matching filename-count issue was found.
getGitConflictCount()normalizes whitespace in unmerged filenames. Two distinct conflicted files nameda b.txtanda b.txtare counted as one, so the GitConflicts widget displays⚠1instead of⚠2.Reproduced on ccstatusline main
3b602348afbbe082eb919b576b55926bbf8d19d6, macOS, Bun 1.3.14, using an isolated real Git index with stages 1, 2 and 3 for each pathname.git ls-files --unmergedreturns six stage records for two paths. Calling the productiongetGitConflictCount()and rendering the production widget returns{count: 1, rendered: "⚠1"}; expected{count: 2, rendered: "⚠2"}. A single-file control passes.The parser in
src/utils/git.tssplits each record on/\s+/and rejoins its pathname with one space, collapsing the two filenames. Quoted filenames containing tabs or newlines can also produce incorrect counts. Git's documentedls-files -zoutput preserves pathnames verbatim and terminates records with NUL, which would permit exact pathname deduplication across stages.I checked the current open PR inventory and the overlapping #631/#632 changes; those address subprocess/cache behavior and leave this parser unchanged. No matching filename-count issue was found.