Re: [RFC/PATCH] rebase -i: add run command to launch a shell command

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Fri, Jul 30, 2010 at 15:24, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Marc Branchaud <marcnarc@xiplink.com> 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/