{"thread":{"id":"20662","subject":"ls-files -t broken? Or do I just not understand it?","startedAt":"2009-08-19T08:24:23Z","lastAt":"2009-08-19T17:53:58Z","messageCount":7,"participants":["Björn Steinbrink","Matthieu Moy","Nguyen Thai Ngoc Duy","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121222","messageId":"20090819082423.GA18860@atjola.homenet","threadId":"20662","inReplyTo":null,"subject":"ls-files -t broken? Or do I just not understand it?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-08-19T08:24:23Z","receivedAt":"2009-08-19T08:24:23Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"Hi,\n\nls-files -t seems to always show status H, even if the file was modified\nor deleted, and thus gets shown by -m and -d respectively.\n\ndoener@atjola:git (master) $ git status\n# On branch master\nnothing to commit (working directory clean)\ndoener@atjola:git (master) $ rm git.c\ndoener@atjola:git (master) $ echo 123 > Makefile\ndoener@atjola:git (master) $ git ls-files -m\nMakefile\ngit.c\ndoener@atjola:git (master) $ git ls-files -d\ngit.c\ndoener@atjola:git (master) $ git ls-files -t Makefile git.c\nH Makefile\nH git.c\ndoener@atjola:git (master) $ git add -u Makefile git.c\ndoener@atjola:git (master) $ git ls-files -m\ndoener@atjola:git (master) $ git ls-files -d\ndoener@atjola:git (master) $ git ls-files -t Makefile git.c\nH Makefile\ndoener@atjola:git (master) $ \n\n\nI would have expected the first \"ls-files -t\" to say:\nC Makefile\nK git.c\n\nIs that a bug, or am I just misunderstanding what -t is supposed to do?\n\nBjörn\n"},{"id":"121226","messageId":"vpqljlguqtn.fsf@bauges.imag.fr","threadId":"20662","inReplyTo":"20090819082423.GA18860@atjola.homenet","subject":"Re: ls-files -t broken? Or do I just not understand it?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-19T08:54:12Z","receivedAt":"2009-08-19T08:54:12Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Björn Steinbrink writes:\n\n> Hi,\n>\n> ls-files -t seems to always show status H, even if the file was modified\n> or deleted, and thus gets shown by -m and -d respectively.\n\nThat's not exactly \"always\", but I don't know whether it's the desired\nbehavior:\n\n/tmp/git$ git st\n# On branch master\n# Changed but not updated:\n# (use \"git add/rm ...\" to update what will be committed)\n# (use \"git checkout -- ...\" to discard changes in working directory)\n#\n# modified: modified\n# deleted: removed\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n/tmp/git$ git ls-files -t \nH modified\nH removed\nH unmodified\n/tmp/git$ git ls-files -t -m\nC modified\nC removed\n/tmp/git$ git ls-files -t -d\nR removed\n$ git ls-files -t -d -m\nC modified\nR removed\nC removed\n\nSo, you get the C and R flags only when you request explicitely -m and\n-d.\n\nI'd say this is a bug, and anyway a testcase should be added to\nexplicitly state what the behavior should be.\n\n-- \nMatthieu\n"},{"id":"121228","messageId":"fcaeb9bf0908190204h31bc839ai39972a251040d449@mail.gmail.com","threadId":"20662","inReplyTo":"vpqljlguqtn.fsf@bauges.imag.fr","subject":"Re: ls-files -t broken? Or do I just not understand it?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2009-08-19T09:04:20Z","receivedAt":"2009-08-19T09:04:20Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy wrote:\n> Björn Steinbrink writes:\n>\n>> Hi,\n>>\n>> ls-files -t seems to always show status H, even if the file was modified\n>> or deleted, and thus gets shown by -m and -d respectively.\n>\n> That's not exactly \"always\", but I don't know whether it's the desired\n> behavior:\n>\n> /tmp/git$ git st\n> # On branch master\n> # Changed but not updated:\n> #   (use \"git add/rm ...\" to update what will be committed)\n> #   (use \"git checkout -- ...\" to discard changes in working directory)\n> #\n> #       modified:   modified\n> #       deleted:    removed\n> #\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> /tmp/git$ git ls-files -t\n> H modified\n> H removed\n> H unmodified\n> /tmp/git$ git ls-files -t -m\n> C modified\n> C removed\n> /tmp/git$ git ls-files -t -d\n> R removed\n> $ git ls-files -t -d -m\n> C modified\n> R removed\n> C removed\n>\n> So, you get the C and R flags only when you request explicitely -m and\n> -d.\n\nLet's see how it goes without \"-t\":\n\npclouds@dektop /tmp/i $ git ls-files\nmodified\nremoved\nunmodified\npclouds@dektop /tmp/i $ git ls-files -m\nmodified\nremoved\npclouds@dektop /tmp/i $ git ls-files -d\nremoved\npclouds@dektop /tmp/i $ git ls-files -d -m\nmodified\nremoved\nremoved\n\nI'd say it's expected behavior.\n-- \nDuy\n"},{"id":"121229","messageId":"20090819091445.GB18860@atjola.homenet","threadId":"20662","inReplyTo":"fcaeb9bf0908190204h31bc839ai39972a251040d449@mail.gmail.com","subject":"Re: ls-files -t broken? Or do I just not understand it?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-08-19T09:14:45Z","receivedAt":"2009-08-19T09:14:45Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.08.19 16:04:20 +0700, Nguyen Thai Ngoc Duy wrote:\n> On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy wrote:\n> > Björn Steinbrink writes:\n> >\n> >> Hi,\n> >>\n> >> ls-files -t seems to always show status H, even if the file was modified\n> >> or deleted, and thus gets shown by -m and -d respectively.\n> >\n> > That's not exactly \"always\", but I don't know whether it's the desired\n> > behavior:\n> >\n> > /tmp/git$ git st\n> > # On branch master\n> > # Changed but not updated:\n> > #   (use \"git add/rm ...\" to update what will be committed)\n> > #   (use \"git checkout -- ...\" to discard changes in working directory)\n> > #\n> > #       modified:   modified\n> > #       deleted:    removed\n> > #\n> > no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> > /tmp/git$ git ls-files -t\n> > H modified\n> > H removed\n> > H unmodified\n> > /tmp/git$ git ls-files -t -m\n> > C modified\n> > C removed\n> > /tmp/git$ git ls-files -t -d\n> > R removed\n> > $ git ls-files -t -d -m\n> > C modified\n> > R removed\n> > C removed\n> >\n> > So, you get the C and R flags only when you request explicitely -m and\n> > -d.\n> \n> Let's see how it goes without \"-t\":\n> \n> pclouds@dektop /tmp/i $ git ls-files\n> modified\n> removed\n> unmodified\n> pclouds@dektop /tmp/i $ git ls-files -m\n> modified\n> removed\n> pclouds@dektop /tmp/i $ git ls-files -d\n> removed\n> pclouds@dektop /tmp/i $ git ls-files -d -m\n> modified\n> removed\n> removed\n> \n> I'd say it's expected behavior.\n\nOK, so -t without _more_ than one of -c, -d, -m, -o, -u, -k simply\ndoesn't make much sense, right?\n\nBjörn\n"},{"id":"121230","messageId":"fcaeb9bf0908190218x487dd7f4y355e411a8cb1f254@mail.gmail.com","threadId":"20662","inReplyTo":"20090819091445.GB18860@atjola.homenet","subject":"Re: ls-files -t broken? Or do I just not understand it?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2009-08-19T09:18:10Z","receivedAt":"2009-08-19T09:18:10Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2009/8/19 Björn Steinbrink :\n> On 2009.08.19 16:04:20 +0700, Nguyen Thai Ngoc Duy wrote:\n>> On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy wrote:\n>> > Björn Steinbrink writes:\n>> >\n>> >> Hi,\n>> >>\n>> >> ls-files -t seems to always show status H, even if the file was modified\n>> >> or deleted, and thus gets shown by -m and -d respectively.\n>> >\n>> > That's not exactly \"always\", but I don't know whether it's the desired\n>> > behavior:\n>> >\n>> > /tmp/git$ git st\n>> > # On branch master\n>> > # Changed but not updated:\n>> > #   (use \"git add/rm ...\" to update what will be committed)\n>> > #   (use \"git checkout -- ...\" to discard changes in working directory)\n>> > #\n>> > #       modified:   modified\n>> > #       deleted:    removed\n>> > #\n>> > no changes added to commit (use \"git add\" and/or \"git commit -a\")\n>> > /tmp/git$ git ls-files -t\n>> > H modified\n>> > H removed\n>> > H unmodified\n>> > /tmp/git$ git ls-files -t -m\n>> > C modified\n>> > C removed\n>> > /tmp/git$ git ls-files -t -d\n>> > R removed\n>> > $ git ls-files -t -d -m\n>> > C modified\n>> > R removed\n>> > C removed\n>> >\n>> > So, you get the C and R flags only when you request explicitely -m and\n>> > -d.\n>>\n>> Let's see how it goes without \"-t\":\n>>\n>> pclouds@dektop /tmp/i $ git ls-files\n>> modified\n>> removed\n>> unmodified\n>> pclouds@dektop /tmp/i $ git ls-files -m\n>> modified\n>> removed\n>> pclouds@dektop /tmp/i $ git ls-files -d\n>> removed\n>> pclouds@dektop /tmp/i $ git ls-files -d -m\n>> modified\n>> removed\n>> removed\n>>\n>> I'd say it's expected behavior.\n>\n> OK, so -t without _more_ than one of -c, -d, -m, -o, -u, -k simply\n> doesn't make much sense, right?\n\nIt shows you whether it's a normal entry (marked as \"H\") or unmerged\nentry (\"M\") as far as I can tell. Junio may give more detail\nexplanation about this command.\n-- \nDuy\n"},{"id":"121272","messageId":"7v1vn7wvce.fsf@alter.siamese.dyndns.org","threadId":"20662","inReplyTo":"fcaeb9bf0908190218x487dd7f4y355e411a8cb1f254@mail.gmail.com","subject":"Re: ls-files -t broken? Or do I just not understand it?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-19T17:45:53Z","receivedAt":"2009-08-19T17:45:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> It shows you whether it's a normal entry (marked as \"H\") or unmerged\n> entry (\"M\") as far as I can tell. Junio may give more detail\n> explanation about this command.\n\nSorry, I won't. I refuse to take responsibility for some \"features\" in\nthis command ;-).\n\nMy recollection is that the \"-t for quick status\" were primarily added to\nsupport a scripted Porcelain that is now defunct, while I was looking the\nother way, eh, rather, back when I was not yet in control of the project.\n\nSome of the options of this command are not useful anymore, not in the\nsense that they no longer work as advertised, but more in the sense that\nthere are better ways to do what they were originally invented for.\n\nFor example, the options \"-[mdt]\" under discussion in this thread were\nprimarily invented as poor-mans' substitute for diff-files when the diff\ninfrastructure was not mature enough. It could have been that people who\nadded these flags did not understand diff---I do not remember. You would\nnotice the apparent inconsistency of its choice of the \"status\" letters,\ncompared with the rest of the system---it is a sign that the \"-t\" feature\nwas never taken seriously by core git developers.\n\nSo I wounld't be surprised if there were bugs lurking around \"-t\" family.\nPatches to fix them are welcome; people's scripts depend on them.\n\nI have to say that ls-files currently is in an unfortunate position. It is\na building block for scripts and it will be kept maintained for that\npurpose. But people still use it even from the command line.\n\nSome options are still the only way to get certain information out of the\nsystem, e.g. \"-v\" to see the assume-unchanged bit. \"-u\" unfortunately is\nstill the quickest way to list the conflicted paths, even though the new\n\"git status -s\" may change this situation. \"-o/-i\" is the kosher way for\nscripts to get the list of untracked and/or ignored paths, but some people\nseem to have learned to use that from the command line. While there is\nnothing _wrong_ in doing so per-se, these days from the command line use\nfor human consumption I tend to think it is much handier to view output\nfrom \"git clean -n\".\n"},{"id":"121273","messageId":"vpqljlfsn9l.fsf@bauges.imag.fr","threadId":"20662","inReplyTo":"7v1vn7wvce.fsf@alter.siamese.dyndns.org","subject":"Re: ls-files -t broken? Or do I just not understand it?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-19T17:53:58Z","receivedAt":"2009-08-19T17:53:58Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano writes:\n\n> So I wounld't be surprised if there were bugs lurking around \"-t\" family.\n> Patches to fix them are welcome; people's scripts depend on them.\n\nIn the particular case of -t, as far as my grep can tell, it's\nuntested, not used in Git itself, and rather unlikely to be used\nelsewhere given it's strange behavior.\n\nI'd say the best thing to to is to keep it, but mark it as deprecated\nin the doc, and point to 'diff --name-status' and 'status' as superior\nalternatives in the doc.\n\n-- \nMatthieu\n"}]}