{"thread":{"id":"31282","subject":"Comparing the working tree with a commit should be independent of the index","startedAt":"2012-08-18T18:36:54Z","lastAt":"2012-08-20T19:16:19Z","messageCount":4,"participants":["Maaartin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"197254","messageId":"502FE0C6.6050106@seznam.cz","threadId":"31282","inReplyTo":null,"subject":"Comparing the working tree with a commit should be independent of the index","fromName":"Maaartin","fromEmail":"grajcar@seznam.cz","sentAt":"2012-08-18T18:36:54Z","receivedAt":"2012-08-18T18:36:54Z","isPatch":false,"sender":{"key":"grajcar@seznam.cz","avatar":null},"body":"I've already posted it to SO [1], but got no satisfactory answer. The command\n\ngit diff mycommit\n\ncompares the working tree against mycommit, so it should not depend on the index. But it does as this example shows:\n\ngit init\necho A > A.txt; git add .; git commit -m A; git branch A\necho B > B.txt; git add .; git commit -m B; git branch B\ngit reset --hard A\necho BB > B.txt\ngit diff B\n\nFile B.txt exists both in the working tree and in the commit B, so a proper diff should be shown.\n\nInstead I get \"deleted file\". Adding the file to the index changes it. This is IMHO a bug.\n\n[1]: http://stackoverflow.com/questions/8452820/how-to-compare-the-working-tree-with-a-commit\n"},{"id":"197267","messageId":"7vvcgfrj8q.fsf@alter.siamese.dyndns.org","threadId":"31282","inReplyTo":"502FE0C6.6050106@seznam.cz","subject":"Re: Comparing the working tree with a commit should be independent of the index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-18T21:19:17Z","receivedAt":"2012-08-18T21:19:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Maaartin writes:\n\n> Instead I get \"deleted file\". Adding the file to the index changes\n> it. This is IMHO a bug.\n\nThere are 7 interesting combinations for the state of a path. It\neither exists in or missing from the commit you are gving to \"git\ndiff\", it either exists in or missing from the index, and it either\nexists in or missing from the working tree. Missing from all is\ntotally uninteresting, so it leaves 7 combinations.\n\nAmong the 7 interesting cases, a path missing from the index have 3\ninteresting cases.\n\n In $commit\tOn filesystem\n\n Yes\t\tYes\n Yes\t\tNo\n No\t\tYes\n\nand your case is the first one. What do you want to see happen for\nother two cases? I would guess \"deleted\" and \"added\", as anything\nelse would not be internally consistent.\n\n\"git diff\" compares contents in the index and in the working tree.\n\"git diff HEAD\" compares contents in HEAD and in the working tree.\n\nThe definition of paths in the working tree in these sentences is\nnot \"all files on the filesystem\", or \"all files on the filesystem,\nfiltered with the ignore mechanism\". It is \"all files on the\nfilesystem that are in the index\", and that is why you see a path\nthat is in the commit and on the filesystem but not in the index\nas deleted.\n\nThis definition worked well for us, because that will give a clean\nsemantics to \"git diff HEAD\": what change would I be recording if I\nsaid \"git commit -a\" at this point?\n\nAnd that is why \"git add\" on the path changes the output as you\nobserved in your message. It is an intended behaviour. If you did\nnot tell Git that you want a path that does not exist in the index\nwith \"git add\", the path will not participate in the next commit\ncreated by \"git commit -a\", and \"git diff HEAD\" should not talk\nabout it. If the path is only in the index, not showing it as\ndeletion as you saw is actually dangerous. \"git commit -a\" will\nrecord the deletion of the path in the commit, even though you\nchecked with the \"git diff HEAD\" before you commit to make sure you\ndidn't change it.\n\nOf course, our definition of the set of working tree files does not\nhave to be the only one. Instead, it could be something that\nchanges the semantics of \"git diff HEAD\" output to: what change\nwould I be recording if I said \"git add -A && git commit\" at this\npoint?\n\nThe updated semantics will be far less useful than the current one,\nbut it still is an understandable one. You could introduce a new\noption (mode of operation to \"git diff\") to make it include\nuntracked but not ignored paths to the set of paths on the working\ntree side of the comparison, but I do not think it is useful.\n\nIn short, I do not think there is a bug in the current behaviour.\n"},{"id":"197431","messageId":"503285A5.1010708@seznam.cz","threadId":"31282","inReplyTo":"7vvcgfrj8q.fsf@alter.siamese.dyndns.org","subject":"Re: Comparing the working tree with a commit should be independent of the index","fromName":"Maaartin","fromEmail":"grajcar@seznam.cz","sentAt":"2012-08-20T18:44:53Z","receivedAt":"2012-08-20T18:44:53Z","isPatch":false,"sender":{"key":"grajcar@seznam.cz","avatar":null},"body":"On 08/18/2012 11:19 PM, Junio C Hamano wrote:\n>> Instead I get \"deleted file\". Adding the file to the index changes\n>> it. This is IMHO a bug.\n>\n> Among the 7 interesting cases, a path missing from the index have 3\n> interesting cases.\n> \n> In $commit\tOn filesystem\n> \n> Yes\t\tYes\n> Yes\t\tNo\n> No\t\tYes\n> \n> and your case is the first one. What do you want to see happen for\n> other two cases? I would guess \"deleted\" and \"added\", as anything\n> else would not be internally consistent.\n\nSure.\n\n> \"git diff\" compares contents in the index and in the working tree.\n> \"git diff HEAD\" compares contents in HEAD and in the working tree.\n> \n> The definition of paths in the working tree in these sentences is\n> not \"all files on the filesystem\", or \"all files on the filesystem,\n> filtered with the ignore mechanism\". It is \"all files on the\n> filesystem that are in the index\", and that is why you see a path\n> that is in the commit and on the filesystem but not in the index\n> as deleted.\n\nThat explains it all.\n\n> This definition worked well for us, because that will give a clean\n> semantics to \"git diff HEAD\": what change would I be recording if I\n> said \"git commit -a\" at this point?\n\nOk, I see. I nearly always inspect changes to be committed via \"git gui\", so I don't care much about what \"git commit -a\" does.\n\n> And that is why \"git add\" on the path changes the output as you\n> observed in your message. It is an intended behaviour. If you did\n> not tell Git that you want a path that does not exist in the index\n> with \"git add\", the path will not participate in the next commit\n> created by \"git commit -a\", and \"git diff HEAD\" should not talk\n> about it. If the path is only in the index, not showing it as\n> deletion as you saw is actually dangerous. \"git commit -a\" will\n> record the deletion of the path in the commit, even though you\n> checked with the \"git diff HEAD\" before you commit to make sure you\n> didn't change it.\n\nThis is a good point. The deletion itself is easily undone, but git wouldn't record the new file content, which could be a problem for me.\n\n> Of course, our definition of the set of working tree files does not\n> have to be the only one. Instead, it could be something that\n> changes the semantics of \"git diff HEAD\" output to: what change\n> would I be recording if I said \"git add -A && git commit\" at this\n> point?\n\nThis was more or less my POW. Or more exactly, I simply just wanted to compare the state seen in the filesystem against an old commit.\n\n> The updated semantics will be far less useful than the current one,\n> but it still is an understandable one. You could introduce a new\n> option (mode of operation to \"git diff\") to make it include\n> untracked but not ignored paths to the set of paths on the working\n> tree side of the comparison, but I do not think it is useful.\n\nSuch a behavior would suit me, but I can live with the current one. There aren't much cases when it makes a difference and git commands have already a lot of options.\n\n> In short, I do not think there is a bug in the current behaviour.\n\nI can live with it. Many thanks for your answer.\n\nDo you care to copy-paste something to [1], so I could accept your answer? Otherwise, I'll do it, so the information is there.\n\n[1]: http://stackoverflow.com/questions/8452820/how-to-compare-the-working-tree-with-a-commit\n\nRegards, Maaartin.\n"},{"id":"197433","messageId":"7vfw7hjrwc.fsf@alter.siamese.dyndns.org","threadId":"31282","inReplyTo":"503285A5.1010708@seznam.cz","subject":"Re: Comparing the working tree with a commit should be independent of the index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-20T19:16:19Z","receivedAt":"2012-08-20T19:16:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Maaartin writes:\n\n> On 08/18/2012 11:19 PM, Junio C Hamano wrote:\n> ...\n>> In short, I do not think there is a bug in the current behaviour.\n>\n> I can live with it. Many thanks for your answer.\n>\n> Do you care to copy-paste something to [1], so I could accept your answer?\n\nI never post to that site, and it has been a long time since I even\nvisited there (I got an impression that nonnegliglble percentage of\naccepted answers were mere crap, and I stopped visiting).\n\nIf you think it would help others, just go ahead and give them a\ncopy and paste with credits. Everything I write here is Open\nSource, so no need to ask for permission.\n\nIt may help them in the longer term to include\n\n http://thread.gmane.org/gmane.comp.version-control.git/203689/focus=203702\n\nto point them to where things happen and where people who matter\nhang around.\n"}]}