{"thread":{"id":"22939","subject":"Re: Determining if a tree is clean","startedAt":"2010-03-06T15:12:42Z","lastAt":"2010-03-06T20:33:22Z","messageCount":3,"participants":["Adam Mercer","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136322","messageId":"799406d61003060712t120d7f11me6e2ab212c55271@mail.gmail.com","threadId":"22939","inReplyTo":null,"subject":"Determining if a tree is clean","fromName":"Adam Mercer","fromEmail":"ramercer@gmail.com","sentAt":"2010-03-06T15:12:42Z","receivedAt":"2010-03-06T15:12:42Z","isPatch":false,"sender":{"key":"ramercer@gmail.com","avatar":"https://gravatar.com/avatar/16dc719817f62b75075d529ce4ea992ee82bb1a08e45a3029797f39223d6ee64?d=mp&s=160"},"body":"Hi\n\nIn one of the projects I work in we have a script which creates a\nheader file containing various commit information, such as the id of\nthe HEAD commit, the date it was committed, who made the commit, and\nif the tree is clean (i.e. no uncommitted changes). In order to\ndetermine if the tree is clean we use the command\n\ngit diff-index --quiet HEAD\n\nand if the this exits with a non-zero return code then we assume that\nthe tree is unclean. However I have found a case when this exits with\na return code of 1 when the tree has no uncommitted changes, e.g.:\n\n$ git diff-index --quiet HEAD\n$ echo $?\n1\n$\n\nand when I look at what file it thinks is unclean I get:\n\n$ git diff-index HEAD\n:100644 100644 3b839718d3f182119db5d9e2b88e516e02ecc00b\n0000000000000000000000000000000000000000 M\nlal/include/lal/LALConfig.h.in\n$ git diff-index -p HEAD\ndiff --git a/lal/include/lal/LALConfig.h.in b/lal/include/lal/LALConfig.h.in\n$\n\nwhich shows no changes in the actual file. This file is the template\nfor a header created using the AC_CONFIG_HEADERS() autoconf macro.\nFrom the above it looks like the build process has created a new file\nwith exactly the same contents as the file specifies in the index. Is\nthere a way that I can tell git-diff-index that this is OK? Or is\nthere another way I can determine if the tree has any uncommitted\nchanges?\n\nI'm seeing this with git-1.7, on Mac OS X 10.6, and git-1.5.5.6, on RHEL5.\n\nCheers\n\nAdam\n"},{"id":"136332","messageId":"7vy6i5fe5h.fsf@alter.siamese.dyndns.org","threadId":"22939","inReplyTo":"799406d61003060712t120d7f11me6e2ab212c55271@mail.gmail.com","subject":"Re: Determining if a tree is clean","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-06T19:23:06Z","receivedAt":"2010-03-06T19:23:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Adam Mercer <ramercer@gmail.com> writes:\n\n> git diff-index --quiet HEAD\n\nIt is expected that a Porcelain script that implements a custom feature\nmay call diff-files, diff-index and other plumbing commands many times\nduring its lifetime, and that it knows what it is doing (namely, when\nit touches the working tree itself and why).\n\nFor this reason, most plumbing commands do not refresh the cached stat\ninformation in the index.  A Porcelain script is responsible for running\n\"update-index --refresh\" once before it makes a call that cached stat\ninformation matters, and as long as it doesn't touch the files in the\nworking tree, it doesn't have to run it again and again.\n\nPorcelain commands like \"git diff\" that are expected to be run directly by\nthe end user cannot assume that, so they do not optimize---they typically\nrefresh the cached stat information by themselves internally whey they\nstart up.\n\nYour Porcelain script should look something like:\n\n    git update-index --refresh\n    git diff-files -q || { echo \"modified working tree\"; exit 1 }\n    git diff-index --cached -q HEAD || { echo \"modified index\"; exit 2 }\n\nSee contrib/examples/*.sh for examples.\n"},{"id":"136314","messageId":"799406d61003061233w60633e26t4c2434042b7f216d@mail.gmail.com","threadId":"22939","inReplyTo":"7vy6i5fe5h.fsf@alter.siamese.dyndns.org","subject":"Re: Determining if a tree is clean","fromName":"Adam Mercer","fromEmail":"ramercer@gmail.com","sentAt":"2010-03-06T20:33:22Z","receivedAt":"2010-03-06T20:33:22Z","isPatch":false,"sender":{"key":"ramercer@gmail.com","avatar":"https://gravatar.com/avatar/16dc719817f62b75075d529ce4ea992ee82bb1a08e45a3029797f39223d6ee64?d=mp&s=160"},"body":"On Sat, Mar 6, 2010 at 13:23, Junio C Hamano <gitster@pobox.com> wrote:\n\n> It is expected that a Porcelain script that implements a custom feature\n> may call diff-files, diff-index and other plumbing commands many times\n> during its lifetime, and that it knows what it is doing (namely, when\n> it touches the working tree itself and why).\n\nMakes sense.\n\n> Your Porcelain script should look something like:\n>\n>    git update-index --refresh\n>    git diff-files -q || { echo \"modified working tree\"; exit 1 }\n>    git diff-index --cached -q HEAD || { echo \"modified index\"; exit 2 }\n>\n> See contrib/examples/*.sh for examples\n\nThanks, Junio. That does the trick, I'd recently found the\nupdate-index command and had run into the problem (but not the\nsolution) that the call to diff-files addresses.\n\nCheers\n\nAdam\n"}]}