Re: Bug in reflog of length 0x2BFF

From: Christoph Mallon <mallon@cs.uni-saarland.de>
Date: Dec 1, 2014, 22:30 UTC
Message-ID: <547CEBE8.8070301@cs.uni-saarland.de>
In-Reply-To: <CAGZ79kaLaWK57m9_1aFOkSubECUvFcEvGjid8EuUmYNUO5Z5jw@mail.gmail.com>

Am 01.12.14 19:53, schrieb Stefan Beller:

> So I am running a 3.13.0-40-generic x86_64 linux (so its's amd64) and
> git version 2.1.2
> and I cannot reproduce the bug you are describing. :(

):

I can reproduce it with
* OS X, i386 binary, git 2.2.0
* FreeBSD, amd64, git 2.1.0 and up (bisected it there)
* FreeBSD, amd64, git 2.1.2 (different machine)

I cannot reproduce it with
* Linux, amd64, git 2.1.0

> $ git rev-parse 'master@{52}'
> 0000000000000000000000000000000000000035

On a machine, where you see the bug, you get entry /0...036/. This btw causes havoc: git stash list shows all entries, but e.g. git stash drop drops the wrong stash after @{52}.

> What I noticed though is there are 2 linefeeds at the end of each
> line, is that intended or did it break during transmission?

That broke.
It should be a normal reflog file.
Try this:
	http://tron.yamagi.org/zeug/reflog.bad

Still 4207ed285f31ad3e04f08254237c0c1a1609642b seems a plausible cause, because it's about reflogs. Though I suspect the actual bug was introduced before, because this commit only uses machinery, which was added earlier.

	Christoph