Nguyen Thai Ngoc Duy [off-list ref] writes:

It shows you whether it's a normal entry (marked as "H") or unmerged
entry ("M") as far as I can tell. Junio may give more detail
explanation about this command.

Sorry, I won't.  I refuse to take responsibility for some "features" in
this command ;-).

My recollection is that the "-t for quick status" were primarily added to
support a scripted Porcelain that is now defunct, while I was looking the
other way, eh, rather, back when I was not yet in control of the project.

Some of the options of this command are not useful anymore, not in the
sense that they no longer work as advertised, but more in the sense that
there are better ways to do what they were originally invented for.

For example, the options "-[mdt]" under discussion in this thread were
primarily invented as poor-mans' substitute for diff-files when the diff
infrastructure was not mature enough.  It could have been that people who
added these flags did not understand diff---I do not remember.  You would
notice the apparent inconsistency of its choice of the "status" letters,
compared with the rest of the system---it is a sign that the "-t" feature
was never taken seriously by core git developers.

So I wounld't be surprised if there were bugs lurking around "-t" family.
Patches to fix them are welcome; people's scripts depend on them.

I have to say that ls-files currently is in an unfortunate position. It is
a building block for scripts and it will be kept maintained for that
purpose.  But people still use it even from the command line.

Some options are still the only way to get certain information out of the
system, e.g. "-v" to see the assume-unchanged bit.  "-u" unfortunately is
still the quickest way to list the conflicted paths, even though the new
"git status -s" may change this situation.  "-o/-i" is the kosher way for
scripts to get the list of untracked and/or ignored paths, but some people
seem to have learned to use that from the command line.  While there is
nothing _wrong_ in doing so per-se, these days from the command line use
for human consumption I tend to think it is much handier to view output
from "git clean -n".