Steven Grimm <koreth@xxxxxxxxxxxxx> writes: > Josef Weidendorfer wrote: >> Why not add a general "--top" option to the "git" wrapper, >> to temporarily let git change to the toplevel while running >> the command? >> > > If I can add a config entry so --top is the default, then that's > acceptable, but IMO it should be the default and we should, at most, > spit out a warning if a command is run in a subdirectory and there's a > chance of confusion. > > When I run one of the commands that currently can't run in a > subdirectory and it spits out its error message, I NEVER react to that > by saying, "Oops, forgot I was in a subdirectory, guess I didn't want > to run that after all." (Have any of you said that, even once?) I agree with you 90% -- the other 10% are: - when these whole-tree operations fail in conflicts, I need to cd to the top to deal with "the other parts" of the tree anyway. - the result of merging other tree may make the current directory disappear (say, I haven't changed anything in the current directory and the other branch moved it to somewhere else, so it cleanly merged but now the current directory should not be there). These worries are only small percentage because most of the merges (or merge-like operations) are clean and directory removal is rare. I would understand why somebody might want to fetch from others while working in subdirectory -- to see what other people might be doing in the same area as you are currently working on. 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. > ... I > react by grimacing and typing "cd" so the command will do what I told > it to do. I have done that every single time I've gotten the > in-a-subdirectory error. And muttering under my breath something along > the lines of, "The code knows everything it needs to know to do what I > just told it to, but it's making me take seconds to do by hand what it > could have done on its own in nanoseconds." I do understand that you would want to cuss --- I probably would if that happened to me, too. However, I am somewhat doubtful to put me in that situation in the first place, because running these five commands would be something I would do when my work-in-progress is somewhat in a stable state (perhaps after creating a temporary commit with "git-commit -a -m WIP" on the current topic branch), and am switching my attention to do something else. Doing one of these five commands (say "rebase") would be the first action of the next stage of my work, but that would most likely be preceded by cd'ing to the top; I am unlikely to stay in the "current subdirectory" when running the "rebase". I most likely am missing something, some obvious thing in your workflow that is not mine. - 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