Jeff King <peff@xxxxxxxx> 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.
