Re: git bisect; is there a way to pick only from the children of a given commit

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 1, 2009, 20:02 UTC
Message-ID: <m38wj8w4s1.fsf@localhost.localdomain>
In-Reply-To: <loom.20090701T170535-707@post.gmane.org>

Robert Stonehouse <rstonehouse@solarflare.com> writes:

Show 28 quoted lines

> I had a problem where I thought git bisect would be a good way forwards.
> It didn't work as expected so I made myself a simpler test-case.
> 
> featureA (which was a new build target) was broken at HEAD. It had been
> developed on the featureA branch. After featureA was merged into master,
> featureB (which had branched from master at the same point as featureA) was
> merged with master.
> 
>   $ git log --graph --abbrev-commit --pretty=oneline
>   * b394c57... master4
>   *   7e8d675... Merge branch 'featureB'
>   |\  
>   | * 8d87aee... featureB2
>   | * c1a8450... featureB1
>   * | 44c5601... master3
>   * |   269602a... Merge branch 'featureA'
>   |\ \  
>   | * | 91b1bbb... featureA2
>   | * | 0c15834... featureA1
>   | |/  
>   * | 1ea4a0c... master2
>   |/  
>   * 204f839... master1
> 
> Tag featureA1 was my good commit, and HEAD was the bad.
> I was surprised that git bisect was asking me to test commits on the featureB
> branch. I couldn't test the build target that was broken on branch featureB
> because it wasn't present in the code at that point.

That is what "git bisect skip [<rev>|<range>...]" is for."

> Is there a way to do what I want (bisect all children of a commit)?

Also in 'pu' there is refs/replace mechanism, which was intendend mainly to "repair" un-bisectable history...

-- 
Jakub Narebski
Poland
ShadeHawk on #git