Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html