On Mon, Mar 20, 2006 at 02:33:56PM +0100, Wouter Verhelst wrote:
> Package: git
This should be git-core, Ian re-assigned.
> Hi,
>
> I'm currently trying to pin down a bug to a specific commit by using
> git-bisect.
>
> However, I stumbled upon a revision that doesn't compile due to a reason
> that (apparently) is unrelated to this bug. While I could try to find
> the fix for that compile problem in one of the later revisions, this is
> a needless digression. I'd much rather have something like "git-bisect
> broken", which tells the system that this commit cannot be verified, and
> if it would please try another one thank you.
Hi Wouter, this is from the git-bisect documentation, what upstream
suggest when git bisect suggest a broken state:
If in a middle of bisect session, you know what the bisect
suggested to try next is not a good one to test (e.g. the change
the commit introduces is known not to work in your environment
and you know it does not have anything to do with the bug you
are chasing), you may want to find a near-by commit and try that
instead. It goes something like this:
$ git bisect good/bad # previous round was good/bad.
Bisecting: 337 revisions left to test after this
$ git bisect visualize # oops, that is uninteresting.
$ git reset --hard HEAD~3 # try 3 revs before what
# was suggested
Sounds like what you need?
Regards, Gerrit.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
