Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> writes: > On Friday 12 January 2007 21:56, Junio C Hamano wrote: >> This updates five commands (merge, pull, rebase, revert and cherry-pick) >> so that they can be started from a subdirectory. >> >> This may not actually be what we want to do. These commands are >> inherently whole-tree operations,... > > Why not add a general "--top" option to the "git" wrapper, > to temporarily let git change to the toplevel while running > the command? > > The wish to allow git-fetch from subdirectories is the > inconvenience to have to cd up, and later down. This is > avoided by running "git --top fetch", and theses people > should be happy. Well, git-fetch does not have anything to do with the working tree, so it does not matter if you run from a subdirectory. You do not even need --top for it (and you don't with v1.5.0-rc1). If we replace "git-fetch" in what you said with one of the commands I listed in the message you quoted, what you said becomes at least internally consistent. But I do not necessarily agree with it. Adding --top and refusing to work without the option gives a false impression that it is a bug that they do not work from the top in the current implementation, and someday we might do these commands limited to the current directory when the user is in a subdirectory. But for the above commands, it is definitely not the case. They are inherently whole-tree operations and it ould actually be a bug to limit their operation to a single subdirectory. For example, what would a "merge" limited to the current directory do? It would probably do the usual 3-way merge for the current directory and apply the 'ours' strategy for the rest of the tree. But that is obviously wrong. The new commit claims that "I considered the whole tree states these two commits record, and came up with this another whole tree this commit records -- it suits my purpose better than either of these other two trees". Future merges that involve the resulting commit will take this statement into account, and will revert the changes the other branch would have brought in outside the current directory if your merge result is later merged into somebody else's tree. Rebasing a series of commits on top of some other branch, but limiting only to the current directory does not make much sense, either; it would lose the changes to the other parts of the tree. Losing the changes to the other parts of the tree might sometimes be what the user would want, but for the most cases that would not be true. Also what the original log messages say would not match the set of partial changes limited to the current directory you are porting forward, so you would need to reword the logs as well if you are limiting its operation to the current directory. In other words, it might be sometimes useful but that is not a "rebase" anymore -- it is something else. The same discussion applies to the last two commands in the list (revert and cherry-pick). So for that reason, I think there are only two valid choices. Either we insist these commands to be run from the top, or we always automatically run these commands by cd'ing to the top ourselves. - 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