Re: git-bisect working only from toplevel dir

[Jeff King <peff@peff.net>]

On Wed, Nov 23, 2011 at 09:09:20PM +0100, Adam Borowski wrote:

> > But from what directory would you expect:
> > 
> >   git bisect run make
> > 
> > to run from? If you use a GNU-ish layout with all of your code in
> > "src/",
> 
> In a vast majority of cases the layout remains constant during the whole
> bisection.

Agreed. But you need to think about what happens when it does not. I
think marking the commit as untestable is probably best, with bisect
barfing a reasonable second. Accidentally marking the commit as "bad" is
probably the worst thing we could do. That would produce a subtly wrong
bisection result.

> > Maybe that commit should be considered indeterminate then?
> 
> Why?  If you're running an automated command, then it will probably fail,
> yeah.  I guess most people bisect manually though, so even in repositories
> that do have this problem, there's someone who can test the given commit
> anyway.

If you're not doing "bisect run", then it is a non-issue, no?  If you
are bisecting by hand, then "git bisect good|bad" will delete your
working directory, and probably your shell will start complaining, and
an intelligent tester will see what happened. This is only a problem for
automated bisection, which does not have such a tester.

> > I dunno. I haven't thought that hard about it. But I don't think it's
> > quite as simple as just telling bisect it's OK to run from a subdir.
> 
> At the very least, generally working with a caveat in corner cases seems to
> be better than outright failing.

To be clear: I think this is a good feature that will help a lot of
people, and I don't think an uncommon corner case should prevent it from
going into git.  But I _do_ think we should consider what happens in the
corner cases and at least fail gracefully, rather than produce subtly
wrong results.

-Peff