Re: http://www.kernel.org/doc/local/git-quick.html#bisect

On Sunday 17 May 2009 16:11:35 Florian Mickler wrote:
Hi!

Sorry. It seems we started off on the wrong foot.

I know that one never ends learning and I am glad you took the
time to write this stuff down because it helps.
So let this be clear between us, i'm not trying to offend you and the
criticism is only about git-quick.html as it is found by google.

I choose the 'the sky is falling' attitude to 'shout into the
woods' and provoke at least some response. (not knowing where or who
the maintainer was... )

You've managed that, yes.

Instead you should use
git bisect skip or
git bisect visualize and choose another commit to test.

I believe that both of those options were implemented _after_ I wrote
the above document. (People keep telling me that the user interface
of git can't be said to "suck" because it keeps changing.)

yes. so my email is all the more relevant, or not?

hg log -v git-quick.html says:

changeset: 101:ae115ea731f2
user: Rob Landley <rob@xxxxxxxxxxx>
date: Tue Aug 19 20:59:33 2008 -0500
files: local/git-quick.html
description:
Rafal Milecki brought the "git bisect skip" command to my attention.

I.E. I added a note about git bisect skip just under a year ago. (Yes, I
maintained revisions of that document in a mercurial archive. No, it wasn't
the only thing in the archive.)

("B" being the bug-introducing changeset, "1" the first tested commit,
"2" the 2nd tested commit, "-" some other commit and "+" some merge or
branchpoint. )

you guess wrong at 1 (this means you classify 1 good.)
second commit is 2 which is good, as there the bug B was never
introduced. so you get 2 as good. which is not the opposite of your
guess.

If you converge all the way to a single changeset and it doesn't reproduce the
bug, you guessed wrong and have to back up. As described.

No mechanism can automatically find a bug that was introduced in a group of
revisions that doesn't build for you, or cannot otherwise get far enough to
reproduce the bug. (For that you have to patch the source to get it to work
will enough you can test for that specific bug.)

The ability to do that sort of thing would presumably be why they
implemented the replay option in the first place.

well, i would say they introduced it so one can doublecheck the tests
if one realizes that maybe unplugging the speakers is overshadowing the
bug "speakers don't work in rc5, but in rc1 they worked". or smth like
that. but this is irrelevant.

So the fact they introduced that feature before "skip" was implemented doesn't
enter into this somehow?

(and that really sucks, because all your compiliations after that
one are _worthless_ ).

No, they demonstrate that the bug isn't in that fork, at which point
you back up and check the other fork.

no... you never know because you
have no way of knowing if the bisection succeeded or not.

You can always either find the first commit that reproduced the bug, or
confirm that the bug was introduced in a versions that doesn't build for you.
The automation doesn't have any more information to work with than the manual
method does; it can't do more than that either.

Apparently, you don't understand the method I described. Obviously, my
description of this method was crap.

But if you defer the decision for that commit (via git-skip) you at
least get a range of commits including the bad
commit, or if the commit immidiatly before the bad commit is
buildable, you even get the right bad commit.

i'm quoting the text that neeeds to be _removed_:

I'm going to give you the benefit of the doubt and assume that
"neeeds" isn't a typo rather than a "badwrong" _word_ indicating how
_falling_ the -=>*[(SKY)]*<=- is today.

if you use git-bisect skip there is the (large) chance that your
skipped commit is based ontop of a test-able commit which already
has the bug

If it's testable, why are you skipping it?

Why would the chance be larger for it to have the bug than to not have the
bug? (And if you think it has the bug, guess that it's bad then.)

Last time somebody poked me about this I added this bit:

Note: you can also tell git itself to skip a commit you can't test
with git bisect skip. Unfortunately, the git-bisect man page gives
this warning about the "skip" command:

But computing the commit to test may be slower afterwards and git
may eventually not be able to tell the first bad among a bad and one
or more "skip"ped commits.

this is nonsense (the ''being slower part'').

Why are you telling _me_ about your dissatisfaction with a quote from the
git-bisect man page?

But you have yet to convince me anything's actually wrong...

of course! i never expect someone to do smth without being convinced.
some do, but thats a sign of not caring, being intimidated or being
stupid.

In this case it would be "not caring", at least not enough to argue with you
about this.

You're insisting that the mention of "git-bisect skip" I added a year ago
wasn't sufficient, and what's there is potentially misleading and harmful to
minors and so on, and thus it is vitally important that several screens worth
of material be removed. (Despite the technique working for me just fine.)

*shrug* I never claimed to be a git expert. I leave that to you.

I've removed the potentially misleading document from kernel.org. There are
plenty of other git tutorials, written by people who know/care far more about
git than I do, and I have no intention of distracting you from them.

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Simple script that locks up my box with recent kernels
    ... Although since it will just select a random commit (well, ... For example, "git bisect" might pick a kernel that just doesn't compile, ... because of some stupid bug that was fixed almost immediately afterwards. ... that simply starts up "gitk" (the default git history visualizer) to show ...
    (Linux-Kernel)
  • Re: Shutdown and Reboot Regression 2.6.25-rc[78]
    ... that is absolutely the case where "git bisect" works the worst. ... single wrong turn will efficiently find a commit that is somewhere totally ... with a suspect kernel just to be absolutely sure you mark a kernel good ... bug in action).. ...
    (Linux-Kernel)
  • Re: http://www.kernel.org/doc/local/git-quick.html#bisect
    ... I wrote it way back when, because I had to learn how to use git ... enough to do a bisect and it wasn't properly documented then. ... git bisect visualize and choose another commit to test. ... bug "speakers don't work in rc5, ...
    (Linux-Kernel)
  • Re: [Bug #12422] 2.6.28-git cant resume from str
    ... been based on some earlier -rc, it might have that bug included. ... I didn't "cherry-pick" that commit. ... # git bisect good a3a798c88a14b35e5d4ca30716dbc9eb9a1ddfe2 ...
    (Linux-Kernel)
  • Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed
    ... Ran 'git remote update', ... Attempted a revert against tip/master, ... truly have made a mistake with the original 'git bisect' process ... version of the sources at the problem commit, ...
    (Linux-Kernel)