Git rebase on a simple commit reorder fail without doing any action

Question

I'm trying to reorder 3 commits.

My current condition is:

A -> B -> C

I would like to rebase and get to this:

A -> C -> B

(just swap commits B and C)

I run the command git rebase -i A.

My editor opens up, I change the picks done and save. Nothing happens.

I notice the following:

When I run the rebase command, my editor opens but also I already see the following in the terminal:

Successfully rebased and updated refs/heads/master.
rm: cannot remove `/path/to/git/repo/.git/rebase-merge': Directory not empty

Even though I still did not do anything after running the rebase command (I did not edit anything yet in my editor).

What am I missing?

After editing the picks and saving, do you also quit the editor? — mkrieger1, Jun 15 '17 at 11:33
My editor is gvim, it is set in the global git core configuration. Yes I quit the editor. But again - the error message appears RIGHT AFTER the editor opens! — galp, Jun 15 '17 at 12:12

score 0 · Accepted Answer · answered Jun 15 '17 at 15:05

It may not seem like it at first, but this is essentially a duplicate of How can I use gvim for svn commit messages under Windows? That is, this is a vim/gvim flags and/or settings issue. (This problem in general occurs with many GUI-based editors, not just gvim, but the cure for each depends on the GUI-based editor.) You are telling Git to run gvim, and Git does so in a way in which gvim delivers a "please edit this other file" request to a separate instance of itself.

Having delivered the request, the gvim that Git ran says: "All done!" It exits successfully and Git thinks this means "all done editing." Git reads the file, which of course is not done—some other instance of gvim is now running, letting you edit the directives file—and Git sees the original unchanged file and does a no-op rebase.

The cure is to instruct the gvim that Git runs to stick around, waiting until the requested file edit is completed. Then when the gvim that Git ran has exited, the file really is done, and Git can proceed to read it. I don't use this particular editor and mode so don't know whether -f as a startup flag, or the .vimrc setting (set guioptions+=f), is superior.

(Aside: the failure to remove the directory occurs because gvim has created a .swp file within it.)

-f worked like a charm. thanks for the verbose explanation. – galp Jun 15 '17 at 15:42 — galp, Jun 15 '17 at 15:42

Git rebase on a simple commit reorder fail without doing any action

1 Answers1