why doesn't "git bisect visualize" show all commit ids from the bisect log

why doesn't "git bisect visualize" show all commit ids from the bisect log

[Toralf Förster]

When run that command immediate after "git bisect start" somebody sees
the full commit range as defined in "git bisect start".

However running that command later after few git bisect steps" somebody
is just presented with the remaining commit interval.

Is this intended ?

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: why doesn't "git bisect visualize" show all commit ids from the bisect log

[Jonathan Nieder]

Hi Toralf,

Toralf Förster wrote:

> When run that command immediate after "git bisect start" somebody sees
> the full commit range as defined in "git bisect start".
>
> However running that command later after few git bisect steps" somebody
> is just presented with the remaining commit interval.
>
> Is this intended ?

"git bisect visualize" is meant as a tool to pin down the culprit
commit that produced a regression.  Sometimes after a few steps the
problematic commit is obvious, which can save some test cycles.

If you want to see the list of commits tested so far, "git bisect log"
can help.  To see the entire bisection state, even outside the
regression window, any old "gitk foo..bar" command will do --- the
bisection state is kept in bisect/* refs that show up in blue.

Can you say a little more about what you're trying to do?  Is the goal
to have a nice visualization of what "git bisect log" shows?  (I'm not
aware of any such tool, and I agree it would be a nice thing.)

Hope that helps,
Jonathan

Re: why doesn't "git bisect visualize" show all commit ids from the bisect log

[Toralf Förster]

On 09/20/2013 08:22 PM, Jonathan Nieder wrote:
> Hi Toralf,
> 
> Toralf Förster wrote:
> 
>> When run that command immediate after "git bisect start" somebody sees
>> the full commit range as defined in "git bisect start".
>>
>> However running that command later after few git bisect steps" somebody
>> is just presented with the remaining commit interval.
>>
>> Is this intended ?
> 
> "git bisect visualize" is meant as a tool to pin down the culprit
> commit that produced a regression.  Sometimes after a few steps the
> problematic commit is obvious, which can save some test cycles.
> 
> If you want to see the list of commits tested so far, "git bisect log"
> can help.  To see the entire bisection state, even outside the
> regression window, any old "gitk foo..bar" command will do --- the
> bisection state is kept in bisect/* refs that show up in blue.
> Can you say a little more about what you're trying to do?  Is the goal
> to have a nice visualization of what "git bisect log" shows?  (I'm not
> aware of any such tool, and I agree it would be a nice thing.)
> 
I'm trying to bisect a (bastard of an) issue in fs/dcache.c of the linux
kernel. Till now I do not have a 100% reliable test scenario.

So often I do mark a commit id accidentally wrongly as bad/good.
Therefore git bisect lands into the "wrong" half. As a consequence all
subsequent bisects are senseless. Visualizing all infos from "git bisect
log" would help to see such mistakes.

<few minutes later>

Ick, and now I'm reading your mail again, tried gitk <start>..<end> -
that's what I want, thx.
I wasn't aware that gitk uses the info from BISECT_LOG :-)

Knowing this helps me to interrupt a "git bisect run ...", restarting my
KDE, continuing the bisecting later and still having the full picture of
the overall git bisect process.

Thx again for clarification.

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3