{"thread":{"id":"54450","subject":"Why does git diff-index show intent-to-add file as \"Added\"?","startedAt":"2020-10-17T16:21:18Z","lastAt":"2020-10-27T20:06:43Z","messageCount":6,"participants":["Pratyush Yadav","Junio C Hamano","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"407804","messageId":"20201017162111.gvisfz2daqvhnjmb@yadavpratyush.com","threadId":"54450","inReplyTo":null,"subject":"Why does git diff-index show intent-to-add file as \"Added\"?","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2020-10-17T16:21:11Z","receivedAt":"2020-10-17T16:21:18Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"Hi,\n\nI have been trying to wrap my head around intent-to-add files to add \nsupport for them in git-gui and one point really confuses me.\n\nSay I do:\n\n $ git add -N foo\n\ngit-gui uses `git diff-index --cached HEAD` to find out the status of \nthe \"staged changes\" and `git diff-files` to find out the status of \n\"unstaged changes\".\n\nIn this case, running diff-files gives:\n\n :000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 A\tfoo\n\nwhich tells git-gui that the file is \"added\" thanks to the 'A'. Makes \nsense. We can infer that the file in intent-to-add because untracked \nfiles are not listed by diff-files.\n\nRunning diff-index gives:\n\n :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A\tfoo\n\nwhich tells git-gui that the file is added to the index thanks to the \n'A'. This makes less sense. The file has not been staged yet so why \nshould it be listed as such?\n\nThis causes problems because we then end up showing the file in both the \n\"Unstaged Changes\" and the \"Staged Changes\" sections, even though the \nfile has no staged changes at all. And `git status` says the same. It \nonly lists foo in unstaged changes.\n\nIn addition, this makes it much more complicated to determine if a file \nmarked as intent-to-add has some parts staged and some others unstaged. \nTo determine that, I have to look at what diff-files says about the \nfile. If it says 'A', then the file has no changes staged. If it says \n'M' then it does. This means I have to look at the status of the \n\"unstaged changes\" section to find out information about the \"staged \nchanges\" section. This makes it much harder to write clean, isolated \nroutines.\n\nIs there something wrong with the mental model I'm using here? How does \ngit-status figure these things out? Or is it really a design mistake? If \nso, what can we do to fix it?\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"407807","messageId":"xmqqimb88v35.fsf@gitster.c.googlers.com","threadId":"54450","inReplyTo":"20201017162111.gvisfz2daqvhnjmb@yadavpratyush.com","subject":"Re: Why does git diff-index show intent-to-add file as \"Added\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-10-17T20:18:38Z","receivedAt":"2020-10-17T20:18:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pratyush Yadav writes:\n\n> In this case, running diff-files gives:\n>\n> :000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 A\tfoo\n\nYes, it says \"when comparing the index and the working tree, working\ntree side has it, and the index side does not, so it is an addition\".\n\nOf course, if it is truly a new file that the index does not even\nknow about, we'd stay silent, but a path that are marked with i-t-a\nbit is what the user told us to keey an eye on, so that is what you\nwould get.\n\n> Running diff-index gives:\n>\n> :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A\tfoo\n\nIf this is \"diff-index HEAD\", then I think it is expected. \"when\ncomparing the HEAD and the working tree, working tree side has it,\nand the tree side does not, so it is an addition.\" Exactly the same\nstory as \"diff-files\".\n\nWhat should happen in \"diff-index --cached HEAD\", I offhand do not\nknow. \"diff-index --cached HEAD\" is a request to compare two trees,\ni.e. the tree that _would_ be produced if you wrote the index out as\na tree (i.e. \"git write-tree\") right now, and the tree of HEAD. So\nI think it may be sensible for the command to behave as if the i-t-a\npath does not even exist in the index when it is run with \"--cached\";\nI may be missing some subtleties that require us to do something\ndifferent, but that is what I would think.\n\n\n"},{"id":"407850","messageId":"55ed2ace-5dfd-55f9-d9a6-da71ff795716@gmail.com","threadId":"54450","inReplyTo":"xmqqimb88v35.fsf@gitster.c.googlers.com","subject":"Re: Why does git diff-index show intent-to-add file as \"Added\"?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2020-10-18T16:00:57Z","receivedAt":"2020-10-18T16:01:03Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 17/10/2020 21:18, Junio C Hamano wrote:\n> Pratyush Yadav writes:\n> \n>> In this case, running diff-files gives:\n>>\n>> :000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 A\tfoo\n> \n> Yes, it says \"when comparing the index and the working tree, working\n> tree side has it, and the index side does not, so it is an addition\".\n> \n> Of course, if it is truly a new file that the index does not even\n> know about, we'd stay silent, but a path that are marked with i-t-a\n> bit is what the user told us to keey an eye on, so that is what you\n> would get.\n> \n>> Running diff-index gives:\n>>\n>> :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A\tfoo\n> \n> If this is \"diff-index HEAD\", then I think it is expected. \"when\n> comparing the HEAD and the working tree, working tree side has it,\n> and the tree side does not, so it is an addition.\" Exactly the same\n> story as \"diff-files\".\n> \n> What should happen in \"diff-index --cached HEAD\", I offhand do not\n> know. \"diff-index --cached HEAD\" is a request to compare two trees,\n> i.e. the tree that _would_ be produced if you wrote the index out as\n> a tree (i.e. \"git write-tree\") right now, and the tree of HEAD. So\n> I think it may be sensible for the command to behave as if the i-t-a\n> path does not even exist in the index when it is run with \"--cached\";\n> I may be missing some subtleties that require us to do something\n> different, but that is what I would think.\n\nIf a user runs `add -N file` then if they run `git reset -p` (which runs \n`git diff-index --cached HEAD`) it will ask them if they want to remove \n`file` from the index. If `diff-index --cached` hid i-t-a entries we'd \nlose that or have to get the i-t-a entries another way. Having said that \nit does seem strange for `diff-index --cached` to be showing i-t-a \nentries. Perhaps `diff-index --cached` should default to \n--ita-invisible-in-index?\n\nBest Wishes\n\nPhillip\n\n"},{"id":"407860","messageId":"xmqqo8kz70xv.fsf@gitster.c.googlers.com","threadId":"54450","inReplyTo":"55ed2ace-5dfd-55f9-d9a6-da71ff795716@gmail.com","subject":"Re: Why does git diff-index show intent-to-add file as \"Added\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-10-18T20:07:24Z","receivedAt":"2020-10-18T20:07:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n>> I think it may be sensible for the command to behave as if the i-t-a\n>> path does not even exist in the index when it is run with \"--cached\";\n>> I may be missing some subtleties that require us to do something\n>> different, but that is what I would think.\n>\n> If a user runs `add -N file` then if they run `git reset -p` (which\n> runs `git diff-index --cached HEAD`) it will ask them if they want to\n> remove `file` from the index. If `diff-index --cached` hid i-t-a\n> entries we'd lose that or have to get the i-t-a entries another\n> way. Having said that it does seem strange for `diff-index --cached`\n> to be showing i-t-a entries. Perhaps `diff-index --cached` should\n> default to --ita-invisible-in-index?\n\nIt probably is a good idea to consider if the implementation of `git\nreset -p` is doing a sensible thing, or relying on a buggy behaviour\nof \"diff-index --cached\" (worse yet, broken \"diff-index --cached\" to\nsuit its needs) and see if it can be written differently.\n"},{"id":"408504","messageId":"20201027120943.skmx6c3crbtu335o@yadavpratyush.com","threadId":"54450","inReplyTo":"xmqqimb88v35.fsf@gitster.c.googlers.com","subject":"Re: Why does git diff-index show intent-to-add file as \"Added\"?","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2020-10-27T12:09:43Z","receivedAt":"2020-10-27T12:25:53Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 17/10/20 01:18PM, Junio C Hamano wrote:\n> Pratyush Yadav writes:\n> \n> > In this case, running diff-files gives:\n> >\n> > :000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 A\tfoo\n> \n> Yes, it says \"when comparing the index and the working tree, working\n> tree side has it, and the index side does not, so it is an addition\".\n> \n> Of course, if it is truly a new file that the index does not even\n> know about, we'd stay silent, but a path that are marked with i-t-a\n> bit is what the user told us to keey an eye on, so that is what you\n> would get.\n> \n> > Running diff-index gives:\n> >\n> > :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A\tfoo\n> \n> If this is \"diff-index HEAD\", then I think it is expected. \"when\n> comparing the HEAD and the working tree, working tree side has it,\n> and the tree side does not, so it is an addition.\" Exactly the same\n> story as \"diff-files\".\n\nIt is `git diff-index --cached HEAD`.\n \n> What should happen in \"diff-index --cached HEAD\", I offhand do not\n> know. \"diff-index --cached HEAD\" is a request to compare two trees,\n> i.e. the tree that _would_ be produced if you wrote the index out as\n> a tree (i.e. \"git write-tree\") right now, and the tree of HEAD. So\n> I think it may be sensible for the command to behave as if the i-t-a\n> path does not even exist in the index when it is run with \"--cached\";\n> I may be missing some subtleties that require us to do something\n> different, but that is what I would think.\n\nThis is what I think too. Can we then treat this as a bug, and work on \nfixing it? Does any subsystem expert have any comments and/or provide \nextra context?\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"408524","messageId":"xmqqsg9zbfhy.fsf@gitster.c.googlers.com","threadId":"54450","inReplyTo":"20201027120943.skmx6c3crbtu335o@yadavpratyush.com","subject":"Re: Why does git diff-index show intent-to-add file as \"Added\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-10-27T20:06:33Z","receivedAt":"2020-10-27T20:06:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pratyush Yadav writes:\n\n> It is `git diff-index --cached HEAD`.\n> \n>> What should happen in \"diff-index --cached HEAD\", I offhand do not\n>> know. \"diff-index --cached HEAD\" is a request to compare two trees,\n>> i.e. the tree that _would_ be produced if you wrote the index out as\n>> a tree (i.e. \"git write-tree\") right now, and the tree of HEAD. So\n>> I think it may be sensible for the command to behave as if the i-t-a\n>> path does not even exist in the index when it is run with \"--cached\";\n>> I may be missing some subtleties that require us to do something\n>> different, but that is what I would think.\n>\n> This is what I think too. Can we then treat this as a bug, and work on \n> fixing it? Does any subsystem expert have any comments and/or provide \n> extra context?\n\nI do not think Phillip considers himself an expert in this area, but\nwhat he pointed out in the thread\n\n http://lore.kernel.org/git/xmqqo8kz70xv.fsf@gitster.c.googlers.com/\n\nis worth listening to.\n"}]}