Re: ls-files -t broken? Or do I just not understand it?

[Nguyen Thai Ngoc Duy <pclouds@gmail.com>]

2009/8/19 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.08.19 16:04:20 +0700, Nguyen Thai Ngoc Duy wrote:
>> On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy<Matthieu.Moy@imag.fr> wrote:
>> > Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>> >
>> >> Hi,
>> >>
>> >> ls-files -t seems to always show status H, even if the file was modified
>> >> or deleted, and thus gets shown by -m and -d respectively.
>> >
>> > That's not exactly "always", but I don't know whether it's the desired
>> > behavior:
>> >
>> > /tmp/git$ git st
>> > # On branch master
>> > # Changed but not updated:
>> > #   (use "git add/rm <file>..." to update what will be committed)
>> > #   (use "git checkout -- <file>..." to discard changes in working directory)
>> > #
>> > #       modified:   modified
>> > #       deleted:    removed
>> > #
>> > no changes added to commit (use "git add" and/or "git commit -a")
>> > /tmp/git$ git ls-files -t
>> > H modified
>> > H removed
>> > H unmodified
>> > /tmp/git$ git ls-files -t -m
>> > C modified
>> > C removed
>> > /tmp/git$ git ls-files -t -d
>> > R removed
>> > $ git ls-files -t -d -m
>> > C modified
>> > R removed
>> > C removed
>> >
>> > So, you get the C and R flags only when you request explicitely -m and
>> > -d.
>>
>> Let's see how it goes without "-t":
>>
>> pclouds@dektop /tmp/i $ git ls-files
>> modified
>> removed
>> unmodified
>> pclouds@dektop /tmp/i $ git ls-files -m
>> modified
>> removed
>> pclouds@dektop /tmp/i $ git ls-files -d
>> removed
>> pclouds@dektop /tmp/i $ git ls-files -d -m
>> modified
>> removed
>> removed
>>
>> I'd say it's expected behavior.
>
> OK, so -t without _more_ than one of -c, -d, -m, -o, -u, -k simply
> doesn't make much sense, right?

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.
-- 
Duy