Re: [RFC/PATCH] rebase -i: add run command to launch a shell command
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 2, 2010, 21:15 UTC
- Message-ID
- <7vwrs8k978.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <vpqwrs9nxi5.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 16 quoted lines
> 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.