@gerhardol I don't know if you noticed but it has the strange side effect that in the filetree, all the files are displayed with the 'add' icon instead of the file type icon (until the grep command is run and after that the icons are good):

@gerhardol I don't know if you noticed but it has the strange side effect that in the filetree, all the files are displayed with the 'add' icon instead of the file type icon (until the grep command is run and after that the icons are good)

I have noticed this, too. I think I will see the cause when I am going to review this later.

There is something still that is not right, but it probably works:
If grep status is set once, icon is updated from that on without manipulating the status (why I got it working without the grep string). But GitItemStatus is set with prefix:
summary: $"{_grepSummaryPrefix}{_fileStatusDiffCalculatorInfo.GrepArguments} {GetDescriptionForRevision(selectedRev.ObjectId)}",

There is something still that is not right, but it probably works: If grep status is set once, icon is updated from that on without manipulating the status (why I got it working without the grep string).

This is not wrong: Icons are cached. If they have already been loaded, they can be used at once.
The loading of icons is triggered for git-grep results only because actual status items have their special icon.

But GitItemStatus is set with prefix: summary: $"{_grepSummaryPrefix}{_fileStatusDiffCalculatorInfo.GrepArguments} {GetDescriptionForRevision(selectedRev.ObjectId)}",

How is this related to this PR?
This summary is used for diff groups (FileStatusWithDescription) but not for single items (GitItemStatus).
For file tree, there is only one "group" without heading.

How is this related to this PR?
This summary is used for diff groups (FileStatusWithDescription) but not for single items (GitItemStatus).
For file tree, there is only one "group" without heading.

I fixed this
The icon was set from the GitItemStatus properties. The check for grepstring was not first but before added.
But there is no pint to look at the status if we know the grep/filetree status already.
The update is slightly shorter and less risky for similar changes

submodules are not displayed correctly after my latest change

Two commits added, left a branch behind and squashed and rebased
ls-files works fine, could remove the special submodule handling too. Some optimizations, probably not possible to see. (I belive that there are no additional async added.)
Limitations in git-doc should be updated.

have not tested with removed submodule

A removed subm is not included in the output, except for git ls-files --no-cached
The attempt to get data is obviously failing
This is a Git issue, ignore

Before the subm information could be incorrect, the following lists also the removed

HEAD

index
it is a bug to attempt getting the treeid here

worktree

--
In diff the behavior is the same as before
New submodule is wrong, but the subm info is not available

If it is actually more efficient than just return items.Select(ParseSingle).WhereNotNull();

(The implementation of WhereNotNull could be turned into Where(item => item is not null) in order to let the IL compiler optimize it. I guess there is also a cost to the statemachine for IEnumerable and yield.)

Do you suggest to change to
items.Select(ParseSingle).WhereNotNull();

Do you suggest to change to

I assume you have changed it because it costs less time / allocations. Then, no.
(When using WhereNotNull, it should be simplified so that the compiler can apply its LINQ optimizations.)

added commit for #12464

edit: also used a few lines from the followup in in #12436 for the #12464 change

squashed, rebased and added #12436 (comment)
Plan to merge tomorrow together with #12421