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

Hi,

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.

I understand that bisect can choose anywhere from the list of commits that are
included in the ancestry of HEAD but excludes commits in the ancestry of 
featureA1
  $ git rev-list --pretty=oneline featureA1..HEAD
  b394c57d13c11ce5bec63b4e3556ea9a308bc196 master4
  7e8d675bb277849d7aaa5c8333f5916455bc3a8a Merge branch 'featureB'
  44c5601dbc4c3988553999098cd29fe2bddc2f77 master3
  8d87aee0793a96f9d606fd33cb32b337a2e0a518 featureB2
  269602a2c5326e475866355986b5dc47f8945b30 Merge branch 'featureA'
  c1a8450e552370cc4efc2ea3bf20bf8456051999 featureB1
  1ea4a0c51d59ff6471f43e1cb19e207b95baef8a master2
  91b1bbbbac551cf315bf6e5e8f7cea988fe8d9e8 featureA2

What I really want to bisect is the list of commits that are children of featureA1 (or alternatively any commit that have an ancestor of featureA1) i.e. featureA2, master{3,4}, merge{A,B}

 $ git rev-list --pretty=oneline --first-parent featureA1..HEAD 
is nearly what I want but I haven't found an option in git-bisect to pass
extra arguments to rev-list. But also --first-parent wouldn't consider
featureA2 in this case.

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

I hope that this description isn't too unreadable! Many thanks

Hi,

On Wed, 1 Jul 2009, Robert Stonehouse wrote:

Why don't you just mark the merge commit that introduced featureA as bad, then?

Ciao, Dscho

On Wed, 1 Jul 2009 17:12:16 +0000 (UTC) Robert Stonehouse <rstonehouse@solarflare.com> wrote:

You can exclude the featureB branch by listing at good. Git will know there is no need to test anything on that branch:

$  git bisect start HEAD featureA1 featureB2

HTH, Sean

Sean Estabrooks wrote:
 > On Wed, 1 Jul 2009 17:12:16 +0000 (UTC)
 > Robert Stonehouse <rstonehouse@solarflare.com> wrote:
 >> 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.
 >
 > You can exclude the featureB branch by listing at good.  Git will 
know there
 > is no need to test anything on that branch:

In my toy example it is easy to identify featureB branch as being independent and marking it as good - but in a real repository it would be much harder as they might be many more merges.

I think if I changed my usage of git bisect good and bad to:
   good => build completes
           OR a revision that does not have the new build target
   bad  => new build target fails
then I think it will converge to the problem commit. So perhaps this was 
just an issue of semantics

Thanks for your help

On Thursday 02 July 2009, Robert Stonehouse wrote:

As Jakub said, when the current commit is untestable, "git bisect skip" is the most logical command to use.

Now if you have more information than just "the current commit is untestable", for example if you know that the current commit is on a side branch that has work unrelated to the breakage you are looking for, and if you know that the branch started from a "good" commit, then you can use "git bisect good" instead, because you know the commit is good even if you have not tested it.

I'd say that it's an issue of information. If you already have the information that some commits are good before testing them, then you should use "git bisect good" even if you can't test them.

Best regards, Christian.

Robert Stonehouse <rstonehouse@solarflare.com> writes:

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

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