{"thread":{"id":"3326","subject":"git-ls-files handling of 'missing' files","startedAt":"2006-02-14T03:46:44Z","lastAt":"2006-02-14T03:56:32Z","messageCount":2,"participants":["Jon Nelson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16083","messageId":"Pine.LNX.4.63.0602132126210.6352@gheavc.wnzcbav.cig","threadId":"3326","inReplyTo":null,"subject":"git-ls-files handling of 'missing' files","fromName":"Jon Nelson","fromEmail":"jnelson-git@jamponi.net","sentAt":"2006-02-14T03:46:44Z","receivedAt":"2006-02-14T03:46:44Z","isPatch":false,"sender":{"key":"jnelson-git@jamponi.net","avatar":null},"body":"\ngit-ls-files appears to treat missing files as both removed /and/ \nmodified, neither of which really seems right. Perhaps a new state, \n'missing', is worthwhile?\n\nAlso, the documentation for git-ls-files is a bit confusing to me:\n\n(aside: I assume that the '?' is a mis-typed '/')\n\nThe documentation confuses me when it says that files marked with a 'K' \nare \"to be killed / other\" - it don't understand why 'killed' and \n'other' are lumped together.\n\nThe docs for git-ls-files indicate that a file marked as 'killed' (wrong \ntense?) is a file that needs to be removed for git-checkout-index to \nsucceed. The manpage doesn't say why git-checkout-index needs to succeed \nor under what conditions git-checkout-index would be invoked. (ie, \"why\" \nshould I manually remove this file).\n\nWould it also be worthwhile to change the terminology used? \nSpecifically, it seems that 'unchanged' is more readily understandable \nthan 'cached', and the past tense of 'killed' throws me. I can offer no \nimprovement there, however.\n\nIt seems to me that files can also exist in the state 'new' or 'added' \n(is this the same as unmerged?) Is there a state for 'conflict'?\n\nSorry for all of the questions, I've really been enjoying using git but \nevery now and again something thows me - tonight it was git-ls-files. \n;-)\n\n--\nJon Nelson <jnelson-git@jamponi.net>\n"},{"id":"16084","messageId":"7vpslqwq33.fsf@assigned-by-dhcp.cox.net","threadId":"3326","inReplyTo":"Pine.LNX.4.63.0602132126210.6352@gheavc.wnzcbav.cig","subject":"Re: git-ls-files handling of 'missing' files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-14T03:56:32Z","receivedAt":"2006-02-14T03:56:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Nelson <jnelson-git@jamponi.net> writes:\n\n> The documentation confuses me when it says that files marked with a 'K' \n> are \"to be killed / other\" - it don't understand why 'killed' and \n> 'other' are lumped together.\n\nI think there is a typo in asciidoc source (probably ?:: is needed).\nWhenever you see funky things in the documentation please first\ncheck the Documentation/that-file.txt to see if you are just\nseeing a bad rendition of what was meant.\n\n> The docs for git-ls-files indicate that a file marked as 'killed' (wrong \n> tense?) is a file that needs to be removed for git-checkout-index to \n> succeed. The manpage doesn't say why git-checkout-index needs to succeed \n> or under what conditions git-checkout-index would be invoked. (ie, \"why\" \n> should I manually remove this file).\n\nThis was from long time ago so I may be misremembering things\nbut it is for D/F conflicts.  index has \"doc/file1\" stored but\nyour working tree has a regular file doc.  To check \"doc/file1\"\nout you would need to remove that file.  Or index has a regular\nfile \"path2\" stored when you have \"path2/file2\" on the working\ntree (hence path2 is a directory), in which case \"path2/file2\"\nneeds to disappear.\n\n> It seems to me that files can also exist in the state 'new' or 'added' \n> (is this the same as unmerged?) Is there a state for 'conflict'?\n\nRemember, ls-files is about index vs working tree files.  It\nworks before your initial commit, and never looks at the HEAD\ncommit.  'new' or 'added' has no meaning.  working tree file is\neither known to be the same (thanks to stat information that is\ncached in the index), known to be different (ditto), or unknown\n(when stat information is stale), relative to index.\n\nUnmerged and conflict should be the same, I think.\n"}]}