{"thread":{"id":"2207","subject":"\"Racy\" GIT","startedAt":"2005-10-24T09:29:52Z","lastAt":"2005-10-24T16:34:14Z","messageCount":2,"participants":["Petr Baudis","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10529","messageId":"20051024092952.GZ30889@pasky.or.cz","threadId":"2207","inReplyTo":null,"subject":"\"Racy\" GIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-10-24T09:29:52Z","receivedAt":"2005-10-24T09:29:52Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hello,\n\n  I've  thought that I might describe the race I've hit the last night\nhere so that if you meet it too, you will have an idea what is going on\nand won't waste your time debugging it, like I did. ;-)\n\n  What did I do:\n\n  echo v1 >file\n  cg-add file\n  cg-commit -m\"v1\"\n\n  echo v2 >file\n  cg-commit -m\"v2\"\n\n  Guess what - the second cg-commit didn't commit the new version of the\nfile. git-diff-index didn't show anything. GIT just didn't care about\nthe change.\n\n  Obviously, the problem was that the stat information was exactly the\nsame after the change (it was in a script, so no ctime change, and the\nsize was the same as well). The solution is to tell git/Cogito about the\nchange explicitly (in Cogito, you can do that e.g. by calling cg-add on\nthe file again). This can be obviously very confusing (and dangerous),\nbut if we want to keep the stat caching, I guess there is no way around\nthis (except for sub-second ctimes, but that effectively killed the stat\ncaching on the filesystems which didn't support it).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10538","messageId":"Pine.LNX.4.64.0510240905340.10477@g5.osdl.org","threadId":"2207","inReplyTo":"20051024092952.GZ30889@pasky.or.cz","subject":"Re: \"Racy\" GIT","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-24T16:34:14Z","receivedAt":"2005-10-24T16:34:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 24 Oct 2005, Petr Baudis wrote:\n> \n>   Guess what - the second cg-commit didn't commit the new version of the\n> file. git-diff-index didn't show anything. GIT just didn't care about\n> the change.\n\nYeah. This is why I wanted to use the \"tv_nsec\" field originally.\n\nAs it is, if you change a file within a second so that the length is the \nsame (and inode stays the same), the stat cache can't help you.\n\nNow, this will only trigger if you do a git-update-index (either directly \nor like in your example, indirectly though doing a commit that does it) \nand then change it again immediately, so in practice it shouldn't matter. \nExcept for scripts.\n\nIn scripts, you can avoid this certain ways:\n\n - add a \"sleep 1\" (gaah, just joking, but it works)\n\n - use \"git-apply --index\" (which updates the index on its own on any \n   files it changes) to apply any patches.\n\n - use an explicit \"git-update-index -- filename\"\n\n - if you actually change the inode number, it should be ok, ie\n\n\tsed script < a > b && mv b a\n\n   will change the inode number, and that should trigger the index tests \n   too. NOTE!! This isn't guaranteed, especially if you do it twice (it \n   might re-use the original one)\n\nNote that \"git-update-index --refresh\" will _not_ work, since it looks if \nit changed. But an explicit filename will force an update if you know it \nchanged.\n\nAnd yes, I guess we should document this in big letters.\n\n(There _are_ actually tricks you can do to make this usually less of an \nissue:\n\n - if the git-update-cache --refresh finds file where the mtime matches \n   the current date. It sets a flag. At the end, it waits for the next \n   second to roll around before returning.\n\nmight work well enough)\n\n\t\tLinus\n"}]}