Re: [PATCH] bisect: allow to run from subdirectories

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

>> This does not depend on "do we have T as a directory?" being the
>> bisection criteria.  The important thing is that the current
>> directory would appear and disappear as the bisection process makes
>> you jump around in the history.
>
> I think that is a good explanation. But I remain somewhat unconvinced
> that it is that big a problem in practice.

It's just the difference in attitude, I would think.  Things like
"rebase" take a more liberal attitude and most of the time things
work out OK because removal of a directory is a rare event and
replacement of a directory with a non-directory is even rarer, but
when things break there is no provision to help users to know how it
broke by diagnosing why the revision cannot be checked out, or why
the directory D the user's shell session is sitting in is now
orphaned and different from the directory D the user thinks he is in
because it was removed (while the user's process is in there) and
then recreated under the same name, or any of the tricky things.

The ideal endgame would be to allow operating from subdirectory
*AND* have provisions for helping users when things go wrong because
the starting subdirectory goes away.  "bisect" works under the more
conservative philosophy (start strict and forbid operation that we
know we didn't spend any effort to avoid taking the user into
dangerous waters---we can allow it later once we make it safer but
not until then).

It would involve a bit of chicken-and-egg, I would guess.  If we
think improving Git is more important than avoiding even occasional
failures imposed on end-users, then the more liberal approach would
be easier to work with---we can allow the command to start from
subdirectory even if we do not do anything to help avoid problems,
let the users hit a snag and have them report it, which would give
us some concrete failure mode to work on.