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

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

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

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.

On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy<Matthieu.Moy@imag.fr> wrote:

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.

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

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 <B.Steinbrink@gmx.de>:

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.

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

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

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

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.