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

Björn Steinbrink [off-list ref] 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

On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy[off-list ref] wrote:

Björn Steinbrink [off-list ref] writes:

quoted

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

On 2009.08.19 16:04:20 +0700, Nguyen Thai Ngoc Duy wrote:

On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy[off-list ref] wrote:

quoted

Björn Steinbrink [off-list ref] writes:

quoted

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

2009/8/19 Björn Steinbrink [off-list ref]:

On 2009.08.19 16:04:20 +0700, Nguyen Thai Ngoc Duy wrote:

quoted

On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy[off-list ref] wrote:

quoted

Björn Steinbrink [off-list ref] writes:

quoted

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

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