rebase -i's todo/done list, was Re: [PATCH] rebase -i: redo tasks that die during cherry-pick

Hi Junio,

On 2015-04-29 19:15, Junio C Hamano wrote:

I decided against this in my original design because I frequently edited the todo list during the rebase run, already back when I had still called it `edit-patch-series.sh` (you will remember that "Saturday project" I reported on IRC).

One example for such an editing happens to me quite frequently: I reorder patches into a more logical order, except that I make mistakes and try to pull a patch too early, i.e. before the code it touches was added. In such a case, I obviously get a merge conflict, and after analysing the problem I have a better idea where to put that patch, which I do by adding a "pick deadbeef" into the `git-rebase-todo` list (these days, I use `git rebase --edit-todo`, of course).

If the list and the "current" pointer would be two different things, it would be way too easy to incur inconsistencies. Even for the inventor of rebase -i.

I think that is only an implementation detail: whether we decrement a pointer or put back a line we moved to another file is essentially the same operation: it is a roll-back. The "more invasive" change I implied was to *avoid* the need for a roll-back, i.e. only move that line (or in your example, increment the pointer) after the operation completed successfully.

My implied change would mean that all the `mark_action_done` calls would have to be moved just before the `record_in_rewritten` calls -- but not all actions have that call. The tricky bit is that there are side effects: `peek_next_command` relies on the current behavior and would have to be adjusted. And that is only the side effect that I can think of off the top of my head.

Ciao, Dscho