Odd behavior while loading divelog file

[Linus Torvalds]

On Fri, Sep 19, 2014 at 11:14 AM, Salvador Cuñat
<salvador.cunat at gmail.com> wrote:
>
> Well,  the issue is not in 4.2-1.
>
> Usually don't use my divelog with the development versions so couldn't
> realize the problem earlier.

So I don't know if you actually build from source, but since there's
been a couple of regression reports I thought I'd mention "git bisect"
in case people don't realize how awesome it is.

*If* you build from source and have some clear bug that you can easily
see and that didn't use to happen, "gti bisect" really makes it
trivial and fast to pinpoint when a bug started happening.

You don't need to know anything about the project to use git bisect,
and not even know programming. All you need to do is able to build and
test. If that is the case, then all you need to do is literally:

  git bisect start
  git bisect good <say what was good here>
  git bisect bad <say what was bad here>

and off you go.

The "what was good" can be as simple as "ORIG_HEAD" (if you notice a
new bug right after a pull that wasn't there before), but it might be
any previous build you did and that worked for you.

The "what was bad" is usually empty, ie just the current state, aka "HEAD".

What will happen is that git will select a half-way point, and now you
just compile that and test it. If it's good, just say "git bisect
good". If it's bad, say (obviously) "git bisect bad". And each time,
git will pick a new one.

It's all a nice "halve the number of commits every time", so even if
your good was a long time ago and there were thousands of commits in
between the bad and the good, you'll need to just do roughly 10-12
builds. If it's less, you'll just need to build/test a handful of
times. And the best thing is, it's entirely automated, and you don't
have to know where the bug is, you just have to be able to say whether
it's good or not.

Now, "git bisect" isn't perfect, and sometimes there are versions of
the code that don't build at all, or have other major problems that
end up meaning you can't test them. Hopefully such problems are rare,
though. There's a few helper tools for that case too, but at that
point it's no longer entirely automatic (you can do "git bisect skip",
but that only works for really simple one-off errors, anything more
complex you might need to pick a test-point manually).

Anyway, this might not work for this case, but I thought I'd mention
it, because it's an easy way for a user to generate a better
bug-report, and you can say exactly which change broke things for you.

             Linus