Elijah Newren <newren@xxxxxxxxx> writes: >> This is one of the reasons why "rebase" (especially "rebase -i") may >> want to insist starting at the top-level of the working tree, like >> "git bisect" does. Because running the command from a subdirectory >> works most of the time until it doesn't, people tend to complain why >> they should go up to the top-level before they can run the command. >> >> And this is why---it causes end-user confusion. > > Makes sense to me; I'll submit a patch. Well, but not too hastily. It is one thing to be firm and resist those who want to loosen "git bisect" to allow it to start in a subdirectory, in order to keep protecting the innocent who are already protected with the current safeguard from confusion. It is entirely a different thing to tighten "git rebase" retroactively to break those who are used to see the command start in a subdirectory. The potential confusion that is caused may be the same between commands, but either change can potentially hurt existing users. I hope your patch would serve as a good discussion starter. We may end up loosening "git bisect" to expose our users to possible confusion, the same one that already exists for users of "git rebase", in the name of consistency, and it might even turn out to be a good change. Or not. In any case, it would be a good opportunity to force people thoroughly think things through. Thanks.
