{"thread":{"id":"37340","subject":"Possible bug v2.0.4: git reflog after a crash","startedAt":"2014-08-13T01:33:45Z","lastAt":"2014-08-13T01:33:45Z","messageCount":1,"participants":["Thanumalayan Sankaranarayana Pillai"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"247639","messageId":"CAJ6LpRqaBpinbF7FfU6hk55EmOLZy32Rjc6M9W+WnyK3LD7MUA@mail.gmail.com","threadId":"37340","inReplyTo":null,"subject":"Possible bug v2.0.4: git reflog after a crash","fromName":"Thanumalayan Sankaranarayana Pillai","fromEmail":"madthanu@cs.wisc.edu","sentAt":"2014-08-13T01:33:45Z","receivedAt":"2014-08-13T01:33:45Z","isPatch":false,"sender":{"key":"madthanu@cs.wisc.edu","avatar":null},"body":"This is about what happens when a Git process gets killed by someone,\nor there is a system crash, and then we try to run Git again on the\nrepository.\n\nWhen I run git-commit after adding a few files to the repository, git\nupdates the .git/refs/heads/master file using rename() to complete the\ncommit. Just before this, git appends some meta-information to the\n.git/logs/HEAD file. If a crash happens such that one of these\noperations has been issued but the other has not, then, running\ngit-reflog in the future seems to silently show wrong information.\nSpecifically, the HEAD@{} and the message of one commit (either the\nin-transaction commit that was being performed during the crash, or\nthe previous commit) is shown against the commit number of the other\ncommit. (I am running git-2.0.4.)\n\nThe situation can be reproduced by killing a git process between the\nappend and the rename, using GDB. (Such a crash can also be caused\nwhen a file system buffers only one of the operations for a longer\ntime and a kernel OOPS happens in-between. Typical re-ordering file\nsystems such as ext4-ordered buffer the append longer than the rename,\nleading to about a 25 second window in-between).\n\nA disclaimer: I am more involved in file system research than in using\nGit expertly, and only noticed this issue while examining Git for a\nresearch project. There is a chance that git-reflog is supposed to\noutput the information it currently outputs, and I am simply expecting\nthe wrong thing from it. Also, we have found a couple of places where\nGit might act wrongly in the event of a system crash if a re-ordering\nfile system is used, apart from the usual fsync-before-rename\nconcerns; these, however, require unusual re-orderings that are not\ndone by most usual file systems. I have not reported them because I\nget the sense that Git is written for an ordered file system; do let\nme know if reporting these will be useful.\n\nExample wrong outputs from git reflog:\n----\n1f9cd01 HEAD@{0}: commit: test2\n1f9cd01 HEAD@{1}: commit (initial): test1\n----\n----\n4550c4a HEAD@{0}: commit (initial): test1\n----\n\nExpected output:\n----\n4550c4a HEAD@{0}: commit: test2\n1f9cd01 HEAD@{1}: commit (initial): test1\n----\n\nThanks,\nThanu\n"}]}