{"thread":{"id":"38088","subject":"Bug in reflog of length 0x2BFF","startedAt":"2014-12-01T15:15:28Z","lastAt":"2014-12-05T19:15:24Z","messageCount":15,"participants":["Christoph Mallon","Stefan Beller","Jonathan Nieder","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"252782","messageId":"547C8610.8080301@cs.uni-saarland.de","threadId":"38088","inReplyTo":null,"subject":"Bug in reflog of length 0x2BFF","fromName":"Christoph Mallon","fromEmail":"mallon@cs.uni-saarland.de","sentAt":"2014-12-01T15:15:28Z","receivedAt":"2014-12-01T15:15:28Z","isPatch":false,"sender":{"key":"mallon@cs.uni-saarland.de","avatar":null},"body":"Hi,\n\nI encountered a strange bug concerning the reflog.\nI suspect some kind of out-of-bounds access.\nThe symptom is:\n\n%git rev-parse 'master@{52}'\nwarning: Log for ref refs/heads/master has gap after Thu, 1 Jan 1970\n00:00:01 +0000.\n0000000000000000000000000000000000000036\n\nTry the following:\n\ngit init gitbug\ncd gitbug\ngit commit --allow-empty -m a\ncp ../reflog.bad .git/logs/refs/heads/master\ngit rev-parse 'master@{52}'\n\nThe source of cp is the attached file.\nThis is from a reflog of stash.\nI just replaced all stuff by dummy values.\nThis does not seem to affect the bug.\nSorry, it must be this long.\n\nSome observations:\n* If you change the length of any line starting at line 3, the symptom\nvanishes.\n (The XXXXX at the line ends are free-form text.)\n* Starting at line three, there are 0x2BFF bytes till the end of file.\n Is there some dynamically growing buffer, which at some point reaches\nthe size 0x2C00?\n* Changing the length of the first two lines has no effect.\n Is the file read backwards?\n* It happens at least with git 2.1.2 (amd64) and 2.2.0 (ia32).\n* 2.0.2 (amd64) and 2.1.0 (amd64) seem not to have this bug.\n\n\nAny ideas?\n\n\tChristoph\n\n\n0000000000000000000000000000000000000037 0000000000000000000000000000000000000036 xxxxxxxxxxxxxxxx 0000000001 +0000\tX\n0000000000000000000000000000000000000036 0000000000000000000000000000000000000035 xxxxxxxxxxxxxxxx 0000000001 +0000\tX\n0000000000000000000000000000000000000035 0000000000000000000000000000000000000034 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000034 0000000000000000000000000000000000000033 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000033 0000000000000000000000000000000000000032 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000032 0000000000000000000000000000000000000031 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000031 0000000000000000000000000000000000000030 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000030 000000000000000000000000000000000000002f xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000002f 000000000000000000000000000000000000002e xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000002e 000000000000000000000000000000000000002d xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000002d 000000000000000000000000000000000000002c xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000002c 000000000000000000000000000000000000002b xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000002b 000000000000000000000000000000000000002a xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000002a 0000000000000000000000000000000000000029 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000029 0000000000000000000000000000000000000028 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000028 0000000000000000000000000000000000000027 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000027 0000000000000000000000000000000000000026 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000026 0000000000000000000000000000000000000025 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000025 0000000000000000000000000000000000000024 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000024 0000000000000000000000000000000000000023 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000023 0000000000000000000000000000000000000022 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000022 0000000000000000000000000000000000000021 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000021 0000000000000000000000000000000000000020 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000020 000000000000000000000000000000000000001f xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000001f 000000000000000000000000000000000000001e xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000001e 000000000000000000000000000000000000001d xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000001d 000000000000000000000000000000000000001c xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000001c 000000000000000000000000000000000000001b xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000001b 000000000000000000000000000000000000001a xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000001a 0000000000000000000000000000000000000019 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000019 0000000000000000000000000000000000000018 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000018 0000000000000000000000000000000000000017 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000017 0000000000000000000000000000000000000016 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000016 0000000000000000000000000000000000000015 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000015 0000000000000000000000000000000000000014 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000014 0000000000000000000000000000000000000013 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000013 0000000000000000000000000000000000000012 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000012 0000000000000000000000000000000000000011 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000011 0000000000000000000000000000000000000010 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000010 000000000000000000000000000000000000000f xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000000f 000000000000000000000000000000000000000e xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000000e 000000000000000000000000000000000000000d xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000000d 000000000000000000000000000000000000000c xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000000c 000000000000000000000000000000000000000b xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000000b 000000000000000000000000000000000000000a xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n000000000000000000000000000000000000000a 0000000000000000000000000000000000000009 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000009 0000000000000000000000000000000000000008 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000008 0000000000000000000000000000000000000007 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000007 0000000000000000000000000000000000000006 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000006 0000000000000000000000000000000000000005 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000005 0000000000000000000000000000000000000004 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000004 0000000000000000000000000000000000000003 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000003 0000000000000000000000000000000000000002 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n0000000000000000000000000000000000000002 0000000000000000000000000000000000000001 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n"},{"id":"252784","messageId":"547C9088.7000800@cs.uni-saarland.de","threadId":"38088","inReplyTo":"547C8610.8080301@cs.uni-saarland.de","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Christoph Mallon","fromEmail":"mallon@cs.uni-saarland.de","sentAt":"2014-12-01T16:00:08Z","receivedAt":"2014-12-01T16:00:08Z","isPatch":false,"sender":{"key":"mallon@cs.uni-saarland.de","avatar":null},"body":"This commit seems to introduce the bug:\n4207ed285f31ad3e04f08254237c0c1a1609642b\n"},{"id":"252800","messageId":"CAGZ79kaLaWK57m9_1aFOkSubECUvFcEvGjid8EuUmYNUO5Z5jw@mail.gmail.com","threadId":"38088","inReplyTo":"547C9088.7000800@cs.uni-saarland.de","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2014-12-01T18:53:24Z","receivedAt":"2014-12-01T18:53:24Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"So I am running a 3.13.0-40-generic x86_64 linux (so its's amd64) and\ngit version 2.1.2\nand I cannot reproduce the bug you are describing. :(\n\n$ git rev-parse 'master@{52}'\n0000000000000000000000000000000000000035\n\nWhat I noticed though is there are 2 linefeeds at the end of each\nline, is that intended or did it break during transmission?\n\nStefan\n"},{"id":"252810","messageId":"547CEBE8.8070301@cs.uni-saarland.de","threadId":"38088","inReplyTo":"CAGZ79kaLaWK57m9_1aFOkSubECUvFcEvGjid8EuUmYNUO5Z5jw@mail.gmail.com","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Christoph Mallon","fromEmail":"mallon@cs.uni-saarland.de","sentAt":"2014-12-01T22:30:00Z","receivedAt":"2014-12-01T22:30:00Z","isPatch":false,"sender":{"key":"mallon@cs.uni-saarland.de","avatar":null},"body":"Am 01.12.14 19:53, schrieb Stefan Beller:\n> So I am running a 3.13.0-40-generic x86_64 linux (so its's amd64) and\n> git version 2.1.2\n> and I cannot reproduce the bug you are describing. :(\n\n):\n\nI can reproduce it with\n* OS X, i386 binary, git 2.2.0\n* FreeBSD, amd64, git 2.1.0 and up (bisected it there)\n* FreeBSD, amd64, git 2.1.2 (different machine)\n\nI cannot reproduce it with\n* Linux, amd64, git 2.1.0\n\n> $ git rev-parse 'master@{52}'\n> 0000000000000000000000000000000000000035\n\nOn a machine, where you see the bug, you get entry /0...036/.\nThis btw causes havoc:\ngit stash list shows all entries, but e.g. git stash drop drops the\nwrong stash after @{52}.\n\n> What I noticed though is there are 2 linefeeds at the end of each\n> line, is that intended or did it break during transmission?\n\nThat broke.\nIt should be a normal reflog file.\nTry this:\n\thttp://tron.yamagi.org/zeug/reflog.bad\n\nStill 4207ed285f31ad3e04f08254237c0c1a1609642b seems a plausible cause,\nbecause it's about reflogs.\nThough I suspect the actual bug was introduced before, because this\ncommit only uses machinery, which was added earlier.\n\n\tChristoph\n"},{"id":"252811","messageId":"20141201233515.GV6527@google.com","threadId":"38088","inReplyTo":"547C8610.8080301@cs.uni-saarland.de","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-12-01T23:35:15Z","receivedAt":"2014-12-01T23:35:15Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Christoph,\n\nChristoph Mallon wrote:\n\n> % git rev-parse 'master@{52}'\n> warning: Log for ref refs/heads/master has gap after Thu, 1 Jan 1970 00:00:01 +0000.\n> 0000000000000000000000000000000000000036\n\nCan you say more? What output did you expect and how does this differ\nfrom it?\n\nI tried, with git 2.2.0,\n\n\tgit init gitbug &&\n\tcd gitbug &&\n\tgit commit --allow-empty -m a &&\n\twget http://tron.yamagi.org/zeug/reflog.bad &&\n\tmv reflog.bad .git/logs/refs/heads/master &&\n\tsha1sum .git/logs/refs/heads/master &&\n\tgit rev-parse 'master@{52}'\n\nThe output:\n\n 9ffe44715d0e542a60916255f144c74e6760ffd0 .git/logs/refs/heads/master\n 0000000000000000000000000000000000000035\n\nCould you make a test script that illustrates and reproduces the\nproblem? I.e., a patch to a file like t/t1410-reflog.sh, such that\nif I run\n\n\tcd git\n\tmake\n\tcd t\n\t./t1410-reflog.sh\n\nthen I can reproduce the bug?\n\nThanks,\nJonathan\n"},{"id":"252814","messageId":"CAGZ79kaO166tzHKRPX2j6BZ=fPRy9VhLGXStGpW4waVekZFJAQ@mail.gmail.com","threadId":"38088","inReplyTo":"20141201233515.GV6527@google.com","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2014-12-02T01:39:02Z","receivedAt":"2014-12-02T01:39:02Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"Hi,\n\nso I have installed git version 2.2.0 currently, because I was trying to\nreproduce \"Bug in reflog of length 0x2BFF\".\n\nNow I was using git as a normal user, rebasing some stuff\n(incidentally the reflog improvements)\nand an error occurred:\n$ git rebase --continue\nerror: Ref refs/heads/todo_sb13_ref-transactions-reflog-as-file is at\nc48602d0aaa11b9099440c647ac028604fde4b14 but expected\nd1bbdc6f161ae7550805d565cad1d930487dad34\nfatal: update_ref failed for ref\n'refs/heads/todo_sb13_ref-transactions-reflog-as-file': Cannot lock\nthe ref 'refs/heads/todo_sb13_ref-transactions-reflog-as-file'.\n\nSo I think we definitely have a bug in the reflog code already in version 2.2.0.\n\nTrying to reproduce the error did not yield success.\n\nThanks,\nStefan\n"},{"id":"252837","messageId":"547D589A.30004@cs.uni-saarland.de","threadId":"38088","inReplyTo":"20141201233515.GV6527@google.com","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Christoph Mallon","fromEmail":"mallon@cs.uni-saarland.de","sentAt":"2014-12-02T06:13:46Z","receivedAt":"2014-12-02T06:13:46Z","isPatch":false,"sender":{"key":"mallon@cs.uni-saarland.de","avatar":null},"body":"Hi Jonathan,\n\nAm 02.12.14 00:35, schrieb Jonathan Nieder:\n> Christoph Mallon wrote:\n>> % git rev-parse 'master@{52}'\n>> warning: Log for ref refs/heads/master has gap after Thu, 1 Jan 1970 00:00:01 +0000.\n>> 0000000000000000000000000000000000000036\n> \n> Can you say more? What output did you expect and how does this differ\n> from it?\n\nsorry, I thought it is obvious that the warning should not be there.\nAs far as I understand the code, this warning is shown, when the old\ncommit id of one entry does not equal the new commit id of its predecessor.\nBut this reflog file does not have such a gap.\nAlso the correct result ist 0...035, not 0...036.\nI.e. one entry is erroneously skipped.\n\n> I tried, with git 2.2.0,\n> \n> \tgit init gitbug &&\n> \tcd gitbug &&\n> \tgit commit --allow-empty -m a &&\n> \twget http://tron.yamagi.org/zeug/reflog.bad &&\n> \tmv reflog.bad .git/logs/refs/heads/master &&\n> \tsha1sum .git/logs/refs/heads/master &&\n> \tgit rev-parse 'master@{52}'\n\nThese steps look right.\n\n> The output:\n> \n> 9ffe44715d0e542a60916255f144c74e6760ffd0 .git/logs/refs/heads/master\n\nThe checksum is fine.\n\n> 0000000000000000000000000000000000000035\n\nYou do not see the bug. |:\n\n> \n> Could you make a test script that illustrates and reproduces the\n> problem? I.e., a patch to a file like t/t1410-reflog.sh [...]\n\nhttp://tron.yamagi.org/zeug/0001-t1410-Test-erroneous-skipping-of-reflog-entries.patch\n(also attached)\n\nThis test works for me at v2.0.4 and fails at v2.1.0 and up (v2.2.0, the\ncurrent master).\nBisect says the symptom appears at 4207ed285f31ad3e04f08254237c0c1a1609642b.\n\n\n\tChristoph\n\n\n>From 82115da194adc42143b8603063e0a419fbbf4928 Mon Sep 17 00:00:00 2001\nFrom: Christoph Mallon \nDate: Tue, 2 Dec 2014 07:03:11 +0100\nSubject: [PATCH] t1410: Test erroneous skipping of reflog entries.\n\n---\n t/t1410-reflog.sh | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 63 insertions(+)\n\ndiff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh\nindex 8cf4461..cb77c27 100755\n--- a/t/t1410-reflog.sh\n+++ b/t/t1410-reflog.sh\n@@ -287,4 +287,67 @@ test_expect_success 'stale dirs do not cause d/f conflicts (reflogs off)' '\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'erroneous skipping of reflog entries' '\n+\tgit checkout -b reflogskip &&\n+\tcat > .git/logs/refs/heads/reflogskip < 0000000001 +0000\tX\n+0000000000000000000000000000000000000036 0000000000000000000000000000000000000035 xxxxxxxxxxxxxxxx 0000000001 +0000\tX\n+0000000000000000000000000000000000000035 0000000000000000000000000000000000000034 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000034 0000000000000000000000000000000000000033 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000033 0000000000000000000000000000000000000032 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000032 0000000000000000000000000000000000000031 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000031 0000000000000000000000000000000000000030 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000030 000000000000000000000000000000000000002f xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000002f 000000000000000000000000000000000000002e xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000002e 000000000000000000000000000000000000002d xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000002d 000000000000000000000000000000000000002c xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000002c 000000000000000000000000000000000000002b xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000002b 000000000000000000000000000000000000002a xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000002a 0000000000000000000000000000000000000029 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000029 0000000000000000000000000000000000000028 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000028 0000000000000000000000000000000000000027 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000027 0000000000000000000000000000000000000026 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000026 0000000000000000000000000000000000000025 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000025 0000000000000000000000000000000000000024 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000024 0000000000000000000000000000000000000023 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000023 0000000000000000000000000000000000000022 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000022 0000000000000000000000000000000000000021 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000021 0000000000000000000000000000000000000020 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000020 000000000000000000000000000000000000001f xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000001f 000000000000000000000000000000000000001e xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000001e 000000000000000000000000000000000000001d xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000001d 000000000000000000000000000000000000001c xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000001c 000000000000000000000000000000000000001b xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000001b 000000000000000000000000000000000000001a xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000001a 0000000000000000000000000000000000000019 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000019 0000000000000000000000000000000000000018 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000018 0000000000000000000000000000000000000017 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000017 0000000000000000000000000000000000000016 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000016 0000000000000000000000000000000000000015 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000015 0000000000000000000000000000000000000014 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000014 0000000000000000000000000000000000000013 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000013 0000000000000000000000000000000000000012 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000012 0000000000000000000000000000000000000011 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000011 0000000000000000000000000000000000000010 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000010 000000000000000000000000000000000000000f xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000000f 000000000000000000000000000000000000000e xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000000e 000000000000000000000000000000000000000d xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000000d 000000000000000000000000000000000000000c xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000000c 000000000000000000000000000000000000000b xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000000b 000000000000000000000000000000000000000a xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+000000000000000000000000000000000000000a 0000000000000000000000000000000000000009 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000009 0000000000000000000000000000000000000008 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000008 0000000000000000000000000000000000000007 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000007 0000000000000000000000000000000000000006 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000006 0000000000000000000000000000000000000005 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000005 0000000000000000000000000000000000000004 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000004 0000000000000000000000000000000000000003 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000003 0000000000000000000000000000000000000002 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+0000000000000000000000000000000000000002 0000000000000000000000000000000000000001 xxxxxxxxxxxxxxxx 0000000001 +0000\tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n+EOF\n+\tgit rev-parse \"@{52}\" > actual 2>&1 &&\n+\techo \"0000000000000000000000000000000000000035\" > expect &&\n+\ttest_cmp expect actual\n+'\n+\n test_done\n-- \n2.1.2\n\n"},{"id":"253090","messageId":"xmqqvblrrwxu.fsf@gitster.dls.corp.google.com","threadId":"38088","inReplyTo":"20141201233515.GV6527@google.com","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-04T20:18:05Z","receivedAt":"2014-12-04T20:18:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Christoph Mallon wrote:\n>\n>> % git rev-parse 'master@{52}'\n>> warning: Log for ref refs/heads/master has gap after Thu, 1 Jan 1970 00:00:01 +0000.\n>> 0000000000000000000000000000000000000036\n>\n> Can you say more? What output did you expect and how does this differ\n> from it?\n>\n> I tried, with git 2.2.0,\n>\n> \tgit init gitbug &&\n> \tcd gitbug &&\n> \tgit commit --allow-empty -m a &&\n> \twget http://tron.yamagi.org/zeug/reflog.bad &&\n> \tmv reflog.bad .git/logs/refs/heads/master &&\n> \tsha1sum .git/logs/refs/heads/master &&\n> \tgit rev-parse 'master@{52}'\n>\n> The output:\n>\n> 9ffe44715d0e542a60916255f144c74e6760ffd0 .git/logs/refs/heads/master\n> 0000000000000000000000000000000000000035\n>\n> Could you make a test script that illustrates and reproduces the\n> problem? I.e., a patch to a file like t/t1410-reflog.sh, such that\n> if I run\n>\n> \tcd git\n> \tmake\n> \tcd t\n> \t./t1410-reflog.sh\n>\n> then I can reproduce the bug?\n\nAmen to that. I am getting the same thing.\n"},{"id":"253093","messageId":"5480C60E.3070903@cs.uni-saarland.de","threadId":"38088","inReplyTo":"xmqqvblrrwxu.fsf@gitster.dls.corp.google.com","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Christoph Mallon","fromEmail":"mallon@cs.uni-saarland.de","sentAt":"2014-12-04T20:37:34Z","receivedAt":"2014-12-04T20:37:34Z","isPatch":false,"sender":{"key":"mallon@cs.uni-saarland.de","avatar":null},"body":"Am 04.12.14 21:18, schrieb Junio C Hamano:\n> Jonathan Nieder writes:\n>> Could you make a test script that illustrates and reproduces the\n>> problem? I.e., a patch to a file like t/t1410-reflog.sh, such that\n>> if I run\n>>\n>> \tcd git\n>> \tmake\n>> \tcd t\n>> \t./t1410-reflog.sh\n>>\n>> then I can reproduce the bug?\n> \n> Amen to that. I am getting the same thing.\n\nI ran reproduce it reliably on multiple machines (OS X, FreeBSD, ia32,\namd64), a friend of mine can, too.\nI already sent a test-patch, here it is again:\n\thttp://tron.yamagi.org/zeug/0001-t1410-Test-erroneous-skipping-of-reflog-entries.patch\nUsing this test, bisect reliably gives\n\t4207ed285f31ad3e04f08254237c0c1a1609642b\nas culprit.\nIt seems that Linux does not exhibit this particular behaviour.\nMaybe there are differences in memory allocation, which mask the symptom.\nStefan Beller experienced some other sporadic bug regarding the reflog:\n\thttp://marc.info/?l=git&m=141748434801505&w=2\n"},{"id":"253102","messageId":"20141204215805.GD19953@peff.net","threadId":"38088","inReplyTo":"5480C60E.3070903@cs.uni-saarland.de","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-04T21:58:05Z","receivedAt":"2014-12-04T21:58:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 04, 2014 at 09:37:34PM +0100, Christoph Mallon wrote:\n\n> Am 04.12.14 21:18, schrieb Junio C Hamano:\n> > Jonathan Nieder writes:\n> >> Could you make a test script that illustrates and reproduces the\n> >> problem? I.e., a patch to a file like t/t1410-reflog.sh, such that\n> >> if I run\n> >>\n> >> \tcd git\n> >> \tmake\n> >> \tcd t\n> >> \t./t1410-reflog.sh\n> >>\n> >> then I can reproduce the bug?\n> > \n> > Amen to that. I am getting the same thing.\n> \n> I ran reproduce it reliably on multiple machines (OS X, FreeBSD, ia32,\n> amd64), a friend of mine can, too.\n\nThanks, I was able to reproduce this easily on an OS X machine.\n\nDoes this patch fix your problem?\n\ndiff --git a/refs.c b/refs.c\nindex f1afec5..42e3a30 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -3052,7 +3052,7 @@ static int show_one_reflog_ent(struct strbuf *sb, each_reflog_ent_fn fn, void *c\n \tint tz;\n \n \t/* old SP new SP name SP time TAB msg LF */\n-\tif (sb->len < 83 || sb->buf[sb->len - 1] != '\\n' ||\n+\tif (sb->len < 83 ||\n \t get_sha1_hex(sb->buf, osha1) || sb->buf[40] != ' ' ||\n \t get_sha1_hex(sb->buf + 41, nsha1) || sb->buf[81] != ' ' ||\n \t !(email_end = strchr(sb->buf + 82, '>')) ||\n\n\nI think the bug is in the reverse-reflog reader in\nfor_each_reflog_ent_reverse. It reads BUFSIZ chunks of the file in\nreverse order, and then parses them individually. If the trailing\nnewline for a line falls directly on the block boundary, we may not have\nit in our current block, and pass the line to show_one_reflog_ent\nwithout a trailing newline. That function is picky about making sure it\ngot a full line.\n\nSo this is a long-standing bug in for_each_reflog_ent_reverse. It just\nshowed up recently because we started using that function for\nread_ref_at_ent.\n\nI haven't confirmed yet, but I suspect the problem shows up on OS X and\nFreeBSD but not Linux because of the definition of BUFSIZ (so it is\nreally probably glibc versus BSD libc). The same bug exists on Linux,\nbut you would need different input to stimulate the newline at the right\nspot.\n\nThe above is a workaround. I think the right solution is probably to\nteach for_each_reflog_ent_reverse to makes sure the trailing newline is\nincluded (either by tweaking the reverse code, or conditionally adding\nit to the parsed buffer).\n\n-Peff\n"},{"id":"253103","messageId":"xmqq7fy7rrpq.fsf@gitster.dls.corp.google.com","threadId":"38088","inReplyTo":"5480C60E.3070903@cs.uni-saarland.de","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-04T22:10:57Z","receivedAt":"2014-12-04T22:10:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christoph Mallon writes:\n\n>> Amen to that. I am getting the same thing.\n>\n> I ran reproduce it reliably on multiple machines (OS X, FreeBSD, ia32,\n\nOh, I do not doubt you see a problem. I am just saying that I don't\nhave an easy entry to the issue without it reproducing for me.\n"},{"id":"253104","messageId":"xmqq388vrrj9.fsf@gitster.dls.corp.google.com","threadId":"38088","inReplyTo":"20141204215805.GD19953@peff.net","subject":"Re: Bug in reflog of length 0x2BFF","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-04T22:14:50Z","receivedAt":"2014-12-04T22:14:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think the bug is in the reverse-reflog reader in\n> for_each_reflog_ent_reverse. It reads BUFSIZ chunks of the file in\n> reverse order, and then parses them individually. If the trailing\n> newline for a line falls directly on the block boundary, we may not have\n> it in our current block, and pass the line to show_one_reflog_ent\n> without a trailing newline.\n\nAhh, thanks for helping spot it. A code that uses BUFSIZ explains\nwhy a single reproduction recipe is platform dependent.\n\n> So this is a long-standing bug in for_each_reflog_ent_reverse. It just\n> showed up recently because we started using that function for\n> read_ref_at_ent.\n> ...\n> The above is a workaround. I think the right solution is probably to\n> teach for_each_reflog_ent_reverse to makes sure the trailing newline is\n> included (either by tweaking the reverse code, or conditionally adding\n> it to the parsed buffer).\n\nSounds correct. Unfortunately I no longer remember how I decided to\ndeal with a line that spans the block boundary in that piece of code\nX-<.\n"},{"id":"253144","messageId":"20141205012854.GA16590@peff.net","threadId":"38088","inReplyTo":"xmqq388vrrj9.fsf@gitster.dls.corp.google.com","subject":"[PATCH] for_each_reflog_ent_reverse: fix newlines on block boundaries","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-05T01:28:54Z","receivedAt":"2014-12-05T01:28:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 04, 2014 at 02:14:50PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I think the bug is in the reverse-reflog reader in\n> > for_each_reflog_ent_reverse. It reads BUFSIZ chunks of the file in\n> > reverse order, and then parses them individually. If the trailing\n> > newline for a line falls directly on the block boundary, we may not have\n> > it in our current block, and pass the line to show_one_reflog_ent\n> > without a trailing newline.\n> \n> Ahh, thanks for helping spot it. A code that uses BUFSIZ explains\n> why a single reproduction recipe is platform dependent.\n\nIt also makes writing portable tests annoying, but I think I managed it\nin the patch below. :)\n\n> > So this is a long-standing bug in for_each_reflog_ent_reverse. It just\n> > showed up recently because we started using that function for\n> > read_ref_at_ent.\n> > ...\n> > The above is a workaround. I think the right solution is probably to\n> > teach for_each_reflog_ent_reverse to makes sure the trailing newline is\n> > included (either by tweaking the reverse code, or conditionally adding\n> > it to the parsed buffer).\n> \n> Sounds correct. Unfortunately I no longer remember how I decided to\n> deal with a line that spans the block boundary in that piece of code\n> X-<.\n\nHere's my proposed fix.\n\n-- >8 --\nWhen we read a reflog file in reverse, we read whole chunks\nof BUFSIZ bytes, then loop over the buffer, parsing any\nlines we find. We find the beginning of each line by looking\nfor the newline from the previous line. If we don't find\none, we know that we are either at the beginning of\nthe file, or that we have to read another block.\n\nIn the latter case, we stuff away what we have into a\nstrbuf, read another block, and continue our parse. But we\nmissed one case here. If we did find a newline, and it is at\nthe beginning of the block, we must also stuff that newline\ninto the strbuf, as it belongs to the block we are about to\nread.\n\nThe minimal fix here would be to add this special case to\nthe conditional that checks whether we found a newline.\nBut we can make the flow a little clearer by rearranging a\nbit: we first handle lines that we are going to show, and\nthen at the end of each loop, stuff away any leftovers if\nnecessary. That lets us fold this special-case in with the\nmore common \"we ended in the middle of a line\" case.\n\nSigned-off-by: Jeff King \n---\nI really needed this rearranging to figure out what the fix\n_should_ be. Now that I did that, I was able to write the above\nparagraph explaining what the minimal fix would be. And I can do that if\nwe prefer. But I think the fact that I had to go through the untangling\nstep first is an indication that maybe the end result is better. Of\ncourse that's all subjective. :)\n\nI waffled on the test script between generating it on the fly (as\nbelow), and just including a complete 8K example that provokes the\nfailure. I don't care about the size that much, but rather on which is\nmore readable. My goal with showing the generation steps was to make it\nclear how we arrived there, but I fear it may have ended up too\nconvoluted to do anyone any good. Opinions welcome.\n\n refs.c | 47 ++++++++++++++++++++++++++++++++++++-----------\n t/t1410-reflog.sh | 30 ++++++++++++++++++++++++++++++\n 2 files changed, 66 insertions(+), 11 deletions(-)\n\ndiff --git a/refs.c b/refs.c\nindex 5ff457e..ccb8834 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -3404,24 +3404,49 @@ int for_each_reflog_ent_reverse(const char *refname, each_reflog_ent_fn fn, void\n \n \t\t\tbp = find_beginning_of_line(buf, scanp);\n \n-\t\t\tif (*bp != '\\n') {\n-\t\t\t\tstrbuf_splice(&sb, 0, 0, buf, endp - buf);\n-\t\t\t\tif (pos)\n-\t\t\t\t\tbreak; /* need to fill another block */\n-\t\t\t\tscanp = buf - 1; /* leave loop */\n-\t\t\t} else {\n+\t\t\tif (*bp == '\\n') {\n \t\t\t\t/*\n-\t\t\t\t * (bp + 1) thru endp is the beginning of the\n-\t\t\t\t * current line we have in sb\n+\t\t\t\t * The newline is the end of the previous line,\n+\t\t\t\t * so we know we have complete line starting\n+\t\t\t\t * at (bp + 1). Prefix it onto any prior data\n+\t\t\t\t * we collected for the line and process it.\n \t\t\t\t */\n \t\t\t\tstrbuf_splice(&sb, 0, 0, bp + 1, endp - (bp + 1));\n \t\t\t\tscanp = bp;\n \t\t\t\tendp = bp + 1;\n+\t\t\t\tret = show_one_reflog_ent(&sb, fn, cb_data);\n+\t\t\t\tstrbuf_reset(&sb);\n+\t\t\t\tif (ret)\n+\t\t\t\t\tbreak;\n+\t\t\t} else if (!pos) {\n+\t\t\t\t/*\n+\t\t\t\t * We are at the start of the buffer, and the\n+\t\t\t\t * start of the file; there is no previous\n+\t\t\t\t * line, and we have everything for this one.\n+\t\t\t\t * Process it, and we can end the loop.\n+\t\t\t\t */\n+\t\t\t\tstrbuf_splice(&sb, 0, 0, buf, endp - buf);\n+\t\t\t\tret = show_one_reflog_ent(&sb, fn, cb_data);\n+\t\t\t\tstrbuf_reset(&sb);\n+\t\t\t\tbreak;\n \t\t\t}\n-\t\t\tret = show_one_reflog_ent(&sb, fn, cb_data);\n-\t\t\tstrbuf_reset(&sb);\n-\t\t\tif (ret)\n+\n+\t\t\tif (bp == buf) {\n+\t\t\t\t/*\n+\t\t\t\t * We are at the start of the buffer, and there\n+\t\t\t\t * is more file to read backwards. Which means\n+\t\t\t\t * we are in the middle of a line. Note that we\n+\t\t\t\t * may get here even if *bp was a newline; that\n+\t\t\t\t * just means we are at the exact end of the\n+\t\t\t\t * previous line, rather than some spot in the\n+\t\t\t\t * middle.\n+\t\t\t\t *\n+\t\t\t\t * Save away what we have to be combined with\n+\t\t\t\t * the data from the next read.\n+\t\t\t\t */\n+\t\t\t\tstrbuf_splice(&sb, 0, 0, buf, endp - buf);\n \t\t\t\tbreak;\n+\t\t\t}\n \t\t}\n \n \t}\ndiff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh\nindex 8cf4461..779d4e3 100755\n--- a/t/t1410-reflog.sh\n+++ b/t/t1410-reflog.sh\n@@ -287,4 +287,34 @@ test_expect_success 'stale dirs do not cause d/f conflicts (reflogs off)' '\n \ttest_cmp expect actual\n '\n \n+# Triggering the bug detected by this test requires a newline to fall\n+# exactly BUFSIZ-1 bytes from the end of the file. We don't know\n+# what that value is, since it's platform dependent. However, if\n+# we choose some value N, we also catch any D which divides N evenly\n+# (since we will read backwards in chunks of D). So we choose 8K,\n+# which catches glibc (with an 8K BUFSIZ) and *BSD (1K).\n+#\n+# Each line is 114 characters, so we need 75 to still have a few before the\n+# last 8K. The 89-character padding on the final entry lines up our\n+# newline exactly.\n+test_expect_success 'parsing reverse reflogs at BUFSIZ boundaries' '\n+\tgit checkout -b reflogskip &&\n+\tz38=00000000000000000000000000000000000000 &&\n+\tident=\"abc 0000000001 +0000\" &&\n+\tfor i in $(test_seq 1 75); do\n+\t\tprintf \"$z38%02d $z38%02d %s\\t\" $i $(($i+1)) \"$ident\" &&\n+\t\tif test $i = 75; then\n+\t\t\tfor j in $(test_seq 1 89); do\n+\t\t\t\tprintf X\n+\t\t\tdone\n+\t\telse\n+\t\t\tprintf X\n+\t\tfi &&\n+\t\tprintf \"\\n\"\n+\tdone >.git/logs/refs/heads/reflogskip &&\n+\tgit rev-parse reflogskip@{73} >actual &&\n+\techo ${z38}03 >expect &&\n+\ttest_cmp expect actual\n+'\n+\n test_done\n-- \n2.2.0.390.gf60752d\n"},{"id":"253145","messageId":"20141205013244.GA16642@peff.net","threadId":"38088","inReplyTo":"20141205012854.GA16590@peff.net","subject":"[PATCH] for_each_reflog_ent_reverse: turn leftover check into assertion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-05T01:32:44Z","receivedAt":"2014-12-05T01:32:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 04, 2014 at 08:28:54PM -0500, Jeff King wrote:\n\n> The minimal fix here would be to add this special case to\n> the conditional that checks whether we found a newline.\n> But we can make the flow a little clearer by rearranging a\n> bit: we first handle lines that we are going to show, and\n> then at the end of each loop, stuff away any leftovers if\n> necessary. That lets us fold this special-case in with the\n> more common \"we ended in the middle of a line\" case.\n> \n> Signed-off-by: Jeff King \n> ---\n> I really needed this rearranging to figure out what the fix\n> _should_ be. Now that I did that, I was able to write the above\n> paragraph explaining what the minimal fix would be. And I can do that if\n> we prefer. But I think the fact that I had to go through the untangling\n> step first is an indication that maybe the end result is better. Of\n> course that's all subjective. :)\n\nI _think_ the patch below is also applicable to the code before my\nboundary-fixing patch. But the rearranging also made me more confident\nin it.\n\n-- >8 --\nSubject: for_each_reflog_ent_reverse: turn leftover check into assertion\n\nOur loop should always process all lines, even if we hit the\nbeginning of the file. We have a conditional after the loop\nends to double-check that there is nothing left and to\nprocess it. But this should never happen, and is a sign of a\nlogic bug in the loop. Let's turn it into a BUG assertion.\n\nSigned-off-by: Jeff King \n---\nOf course I cannot say something like \"this can never happen; the old\ncode was wrong to handle this case\" without a nagging feeling that I am\nmissing something, so extra careful eyes are appreciated (and are why I\nwould rather have an assert here than removing the code and silently\ndropping lines if I am wrong).\n\n refs.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/refs.c b/refs.c\nindex ccb8834..1f77fa6 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -3451,7 +3451,7 @@ int for_each_reflog_ent_reverse(const char *refname, each_reflog_ent_fn fn, void\n \n \t}\n \tif (!ret && sb.len)\n-\t\tret = show_one_reflog_ent(&sb, fn, cb_data);\n+\t\tdie(\"BUG: reverse reflog parser had leftover data\");\n \n \tfclose(logfp);\n \tstrbuf_release(&sb);\n-- \n2.2.0.390.gf60752d\n"},{"id":"253177","messageId":"xmqqsigtq56b.fsf@gitster.dls.corp.google.com","threadId":"38088","inReplyTo":"20141205013244.GA16642@peff.net","subject":"Re: [PATCH] for_each_reflog_ent_reverse: turn leftover check into assertion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-05T19:15:24Z","receivedAt":"2014-12-05T19:15:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I _think_ the patch below is also applicable to the code before my\n> boundary-fixing patch. But the rearranging also made me more confident\n> in it.\n\nYeah, thanks for a fix.\n\n> -- >8 --\n> Subject: for_each_reflog_ent_reverse: turn leftover check into assertion\n>\n> Our loop should always process all lines, even if we hit the\n> beginning of the file. We have a conditional after the loop\n> ends to double-check that there is nothing left and to\n> process it. But this should never happen, and is a sign of a\n> logic bug in the loop. Let's turn it into a BUG assertion.\n>\n> Signed-off-by: Jeff King \n> ---\n> Of course I cannot say something like \"this can never happen; the old\n> code was wrong to handle this case\" without a nagging feeling that I am\n> missing something, so extra careful eyes are appreciated (and are why I\n> would rather have an assert here than removing the code and silently\n> dropping lines if I am wrong).\n>\n> refs.c | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/refs.c b/refs.c\n> index ccb8834..1f77fa6 100644\n> --- a/refs.c\n> +++ b/refs.c\n> @@ -3451,7 +3451,7 @@ int for_each_reflog_ent_reverse(const char *refname, each_reflog_ent_fn fn, void\n> \n> \t}\n> \tif (!ret && sb.len)\n> -\t\tret = show_one_reflog_ent(&sb, fn, cb_data);\n> +\t\tdie(\"BUG: reverse reflog parser had leftover data\");\n> \n> \tfclose(logfp);\n> \tstrbuf_release(&sb);\n"}]}