Sean Estabrooks wrote:
> On Wed, 1 Jul 2009 17:12:16 +0000 (UTC)
> Robert Stonehouse <rstonehouse@xxxxxxxxxxxxxx> 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
--
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