'EDITOR=false git add -e' adds to index
In contrast to most other git commands, git add -e does not check whether the editor it invokes exits successfully. This means that if you cause your editor to exit unsuccessfully, hoping to abort the add -e, the add -e continues anyway.
The specific instance I've observed is that you set EDITOR to a program that starts the editor outside the current terminal and waits for it to exit. Then you realize you didn't want to add anything and type ^C in the terminal where git is waiting for $EDITOR to finish. That makes $EDITOR exit unsuccessfully, and git prints an error about not being able to invoke the editor, but it continues on with the add -e, adding everything from the patch to the index.
I am using the acme editor, but I believe that EDITOR='emacs -nw' or EDITOR='subl -w' for Sublime Text are more common settings that would have the same problem. In a test, EDITOR=false suffices.
The root cause seems to be that builtin/add.c's edit_patch does not check the result of the launch_editor call. It probably should.
The call to launch_editor in builtin/config.c should probably also be checked, although there it's not as big a deal, provided the editor did not modify the file; reapplying the same file should be a no-op. This is different from git add -e.
I am seeing this behavior with git 2.2.1, but I checked the main repo and commit c518059 from yesterday still has the unchecked launch_editor call.
Thanks.
Russ
PATCH 1/1 add: check return value of launch_editor
Quoted 2 lines · Russ Cox
The root cause seems to be that builtin/add.c's
edit_patchdoes not check the result of thelaunch_editorcall. It probably should.
Yes, definitely. Patch is below.
Quoted 4 lines
The call to
launch_editorinbuiltin/config.cshould probably also be checked, although there it's not as big a deal, provided the editor did not modify the file; reapplying the same file should be a no-op. This is different from git add -e.
This one is trickier. Certainly we could propagate the return value and say "hey, editing did not work". But we otherwise have no operation to abort. This is because "git config --edit" does not actually take our normal dot-lock, but rather edits the file in place.
IMHO this is questionable, as proper locking seems like half of the purpose of "config --edit" (the other half being that you do not have to type the location of the config file yourself). But I wonder if switching it would make people unhappy, as it would probably break editor rules to do syntax highlighting (e.g., if they are looking for "*/.gitconfig" in the path).
-- >8 --
Subject: add: check return value of launch_editor
When running "add -e", if launching the editor fails, we do not notice and continue as if the output is what the user asked for. The likely case is that the editor did not touch the contents at all, and we end up adding everything.
--- builtin/add.c | 3 ++- t/t3702-add-edit.sh | 7 +++++++ 2 files changed, 9 insertions(+), 1 deletion(-)
builtin/add.c +2 -1
@@ -208,7 +208,8 @@ static int edit_patch(int argc, const char **argv, const char *prefix)if (run_diff_files (&rev,0 ))die (_ ("Could not write patch" )); -launch_editor (file,NULL ,NULL ); +if (launch_editor (file,NULL ,NULL )) +die (_ ("editing patch failed" ));if (stat (file, &st))die_errno (_ ("Could not stat '%s'" ), file);
t/t3702-add-edit.sh +7 -0
@@ -118,4 +118,11 @@ test_expect_success 'add -e' ' ' +test_expect_success 'add -e notices editor failure' ' + git reset --hard && + echo change >>file && + test_must_fail env GIT_EDITOR=false git add -e && + test_expect_code 1 git diff --exit-code +' + test_done
Signature · 1 line
2.4.0.192.g5f8138b
Re: [PATCH] add: check return value of launch_editor
Hi Peff,
Quoted 6 lines · Jeff King
Quoted 2 lines · Russ Cox
The root cause seems to be that builtin/add.c's
edit_patchdoes not check the result of thelaunch_editorcall. It probably should.Yes, definitely. Patch is below.
Thanks for cleaning up my mess!
Ciao,
Dscho