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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
