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

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

[Björn Steinbrink]

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.

doener@atjola:git (master) $ git status
# On branch master
nothing to commit (working directory clean)
doener@atjola:git (master) $ rm git.c
doener@atjola:git (master) $ echo 123 > Makefile
doener@atjola:git (master) $ git ls-files -m
Makefile
git.c
doener@atjola:git (master) $ git ls-files -d
git.c
doener@atjola:git (master) $ git ls-files -t Makefile git.c
H Makefile
H git.c
doener@atjola:git (master) $ git add -u Makefile git.c
doener@atjola:git (master) $ git ls-files -m
doener@atjola:git (master) $ git ls-files -d
doener@atjola:git (master) $ git ls-files -t Makefile git.c
H Makefile
doener@atjola:git (master) $ 


I would have expected the first "ls-files -t" to say:
C Makefile
K git.c

Is that a bug, or am I just misunderstanding what -t is supposed to do?

Björn

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

[Matthieu Moy]

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.

I'd say this is a bug, and anyway a testcase should be added to
explicitly state what the behavior should be.

-- 
Matthieu

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

[Nguyen Thai Ngoc Duy]

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

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

[Björn Steinbrink]

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?

Björn

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

[Nguyen Thai Ngoc Duy]

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

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

[Junio C Hamano]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> 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".

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

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

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

In the particular case of -t, as far as my grep can tell, it's
untested, not used in Git itself, and rather unlikely to be used
elsewhere given it's strange behavior.

I'd say the best thing to to is to keep it, but mark it as deprecated
in the doc, and point to 'diff --name-status' and 'status' as superior
alternatives in the doc.

-- 
Matthieu