Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 13, 2009, 08:33 UTC
Message-ID: <7vtyy3zo9m.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4AD43002.5080003@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 11 quoted lines

> Junio C Hamano schrieb:
>> Half of the time, the commit you test in your "git bisect" section would
>> be a "good" one, and immediately after you tell it "bisect good", it tells
>> you that some _other_ commit you marked "bad" is the first bad commit.  In
>> such a case, you won't be on the commit that the bisect has found.
>
> Oh, yes, very true; but it is very close. But the commit that git bisect
> reset warps me to is perhaps 1000 steps in history away. I certainly do
> not want to go there, ever, because I want to go back near the bad commit
> right away. (Think of fewer files changed means less build time.) If git
> bisect reset would check out the bad commit, this would be *very* convenient.

I agree that "git bisect reset-and-detach-at-the-first-bad-one" would make a lot of sense.

In my workflow, after I chased a bug in frotz, I often do

    $ git name-rev $the_bad_one_that_was_found
    
to learn what was the first tagged release that has the bug, and create a
topic from there:

    $ git checkout -b jc/maint-X.Y.Z-fix-frotz $the_bad_one_that_was_found

so that the fix I'd build on the commit can be merged initially to 'pu', then 'next', then 'maint-X.Y.Z' and upwards to 'master', but all of that is done after "git bisect reset" to switch back to the 'master' branch. It is cumbersome to have to type (actually, I use the cut buffer in screen) the commit object name of the first bad one twice.

It certainly sounds attractive if we can do:

    $ git bisect reset-and-detach-at-the-first-bad-one
    $ git name-rev HEAD
    $ git checkout -b jc/maint-X.Y.Z-fix-frotz
    $ hack hack hack
    $ git commit

But at that point we are not talking about switching to arbitrary commit anymore.