git lfs status both --porcelain and --json flags produce output unusable for programs compared to regular git lfs status

[mordof]

I'm making a Git GUI client geared more specifically for game dev with our desired workflow. Included in this is a need to identify the status of lfs files specifically so they can be marked/handled as such in the gui. The only option I can see is to use the plain user-based git lfs status though, because --porcelain and --json produce either problematic, or incomplete, responses.
Am I missing another feature that provides this? or is this perhaps in the works currently?

More info:
Running git lfs status shows all the details of each file in the regular status, but includes non-lfs files. It does, however, show a Git: <hash> in parenthesis, so it at least gives an indication that it's a regular git file.
Running git lfs status --porcelain however includes regular code files, but critically does not note the difference between git files and lfs files. So that command doesn't work for a scenario a program wants to parse lfs status.
Running git lfs status --json gives better output in that it does not include regular git files, however it critically does not include untracked files yet, despite git lfs status having an understanding of that. similarly, git lfs ls-files also shows an understanding that the untracked file is for lfs.

ChatGPT recommended I take git lfs status --porcelain and then filter it through git lfs ls-files, but that's a really heavy handed way to handle this situation, especially if there are a significant number of files in the repo.

Would it be possible to have a flag added for git lfs status that accurately describes the lfs files themselves for all of the status information?

System environment
Windows 11 Powershell.
git-lfs/2.13.3 (GitHub; windows amd64; go 1.16.2; git a5e6585)
git version 2.33.0.windows.2

[mordof]

Ah, it looks like I was mistaken about git lfs status showing untracked files at all.

It would be great to have something like git status -z, but with the ability to distinguish lfs files essentially is what would be really useful.

[chrisd8088]

Hey, thanks for the explanation of the issue and suggestion for an enhancement; I've marked this as such, and we'll see if someone can get to it in a future release.

It might have to wait for a major release like v4.0.0 if we're changing the output of either the --json or --porcelain options to include files which weren't previously included, even if they are marked as such, since this might upset existing use cases which depend on the current output to not include untracked files.

A feature like NUL-terminated output with -z, of course, could be introduced sooner in a minor release.

As always, if anyone has time to contribute a patch, we'd be excited to review it, but in the meantime I'll put this on the project board as a potential enhancement. Thanks again for the suggestion!