Sangeeta NB <sangunb09@xxxxxxxxx> writes: > Yes, I agree. We need to make some changes in `git rebase` to make it > work from the subdirectory, but that doesn't mean that we should > completely restrict it from running in the subdirectory, and the same > follows for `git bisect`. You actually don't have to make "bisect" work from the subdirectory. You instead can detect the case where your $cwd may be made to disappear, and allow "git bisect" to continue if you are certain that you are not in the funny situation. You need to protect the user from funny situation by refusing to run from a subdirectory only when needed. Besides, as Phillip mentioned, there is a big difference between two commands, isn't it? "git rebase" would ask for help to the end-user by returning the control when anything goes wrong (e.g. it may not be able to replay a commit while the user is sitting in a directory that has already gone), but "git bisect run" would just interpret any failure, not just the ones that are caused by genuine test failure but caused by $cwd going away, as "we saw a bad revision". It would cause a lot of wasted cycles, instead of immediately stopping when there is trouble. So the first thing that has to happen if we want to allow "bisect" to run from anywhere is to teach it to detect when the $cwd went away, and stop to give control back to the user to deal with the situation (it might be the matter of "cd /path/to/top" at that point), instead of blindly continuing. Only after that is in place, we can safely allow it to start from a subdirectory. Thanks.