Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > On Fri, Jul 30, 2010 at 15:24, Matthieu Moy > <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: >> Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: >> >>>> The name of the command may be subject to discussions. I've chosen >>>> "run", but maybe "shell" would be OK too. In both cases, it doesn't >>>> allow the one-letter version since both "r" and "s" are already used. >>> >>> "exec" with one-letter "x"? >> >> Thanks, that sounds good, yes. Any other thought? > > I like "exec". Yes, it's the best proposal IMHO. "x" is very often associated to "execute", and I'd rather keep away from punctuation/shift combo. There have been discussions in the past about giving "!" a semantics (like "fixup!" for a variant of "fixup"). Let's keep this as an option for the future by not using ! now. > I think the docs need to elaborate on the environment the "exec" > command gets executed in, what's its current working directory for > instance? Wherever I happened to run git-rebase from? the project > root? 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. > your if ! eval .. error message also exits with 0, surely that should > exit with 1? I'm now exiting with the same status as the command itself in case of failure. New version follows. It should hopefully look more like a real patch than an RFC now. -- 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