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

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

[Robert Stonehouse]

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

-- 
Rob Stonehouse

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

[Johannes Schindelin]

Hi,

On Wed, 1 Jul 2009, Robert Stonehouse wrote:

> 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.

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

Ciao,
Dscho

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

[Sean Estabrooks]

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

>   $ 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.

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

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

[Jakub Narebski]

Robert Stonehouse <rstonehouse@solarflare.com> writes:

> 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

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

[Robert Stonehouse]

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

-- 
Rob Stonehouse

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

[Christian Couder]

On Thursday 02 July 2009, Robert Stonehouse wrote:
>
> 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.

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 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

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.