Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > That's a good question. My original patch was running the command from > the toplevel, which is the natural way to implement it. I've changed > my mind to execute the command from the place where "git rebase -i" > was started (which means this has to be memorized in a temporary file > to be persistant accross "git rebase --continue"). I think this makes > more sense for the user, and I've actually already been biten by the > old behavior, running "rebase -i" from a doc/ subdirectory, and > wondering why my "exec make" was rebuilding the code itself. > > This comes with at least one drawback: if directory from which the > rebase was started didn't exist in the past, then we can't do a simple > "cd" to it. My implementation re-creates the directory temporarily, so > that the command can run, and cleans it up afterwards. The only really > problematic case is when the directory can not be created (like > directory/file conflict). It this case, the command is not ran, and > the script exits. Sorry to join the discussion after you have already coded it, but I don't think running the external command at a random subdirectory that the operation happened to have started makes much sense, as rebase is a tree-wide operation. The user if s/he so chooses can chdir down (if the directory still exists in the revision in question) in the script, but I think the built-in behaviour should be to just run it from the toplevel. -- 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