Junio C Hamano wrote:
I consider that being in a subdirectory means the user is in the middle of actively working on something in that area. Honestly I do not understand why anybody would want to run the five whole-tree commands under discussion (merge, pull, rebase, revert and cherry-pick) in the middle of doing something, so from the theoretical point of view I would agree that it makes sense for the commands to internally cd-up to do their work, I am not sure how much practical value it would add.
Here's one use case for merge/pull/rebase that is, if not an everyday thing, then at least fairly common in my group: Person B fixes a bug in some code that's causing problems for the code person A is working on. Person A is not at a stopping point in his own work yet, but wants to get the fix.
Revert and cherry-pick are less common here but consider this: some people want submodule support because they're working on a specific part of the tree. They only cd into a subdirectory because there's no way for them to make that subdirectory the top level of their local repository. The fact that there are siblings of their current directory is just an artifact of the project layout and has nothing to do with what they're doing at the moment.
For example, on a simple Web project, the UI designers will always cd to the "html" directory. They get "src" and "lib" too, but if they had a choice they wouldn't. When they cherry-pick, it'll always be a cherry-pick of their own stuff (in the html directory) and likewise with a revert, so they have no reason to cd-up for any of those operations if the tool doesn't demand it. And perhaps less obvious: in a typical shared integration area setup, they will never have any conflicts anywhere but their subdirectory since the other directories will always be able to fast-forward merge. So cd-up isn't useful for them even in the case of merge conflicts.
-Steve - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html