Junio C Hamano <gitster@xxxxxxxxx> writes: > 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. I'm waiting for other people's opinion, since I'm still not 100% convinced, but this seems to reflect the majority's opinion. And the simplicity of the code also is an argument: even if the "I'm too lazy to code it" is not applicable anymore, the simplest version will also be the simplest to maintain. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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