Hi, This has been a long time since I have not given an update on this -- sorry about that. I think it’s time to do it. Le 29/07/2019 à 11:38, Phillip Wood a écrit : > Hi Alban > > -%<- > > That's an interesting point about `--continue`. Perhaps if `--edit-todo` > detects deleted lines in error mode it should write a file to stop > `--continue` continuing rather than having to validate the entire list > each time we continue a rebase. Alternatively we could annotate the todo > list with a message the dropped commits commented out and reopen the > editor for the user to fix the problem, but that would cause scripted > editors to enter a infinite loop as they're unlikely to fix the problem > the second time round. A third possibility is to keep your code > validating the list each time we run continue, but update the backup > file with each edit so it detects added commits that are deleted in a > later edit. This would also provide some protection for users who edit > git-rebase-todo directly, though if they are using a script that deletes > lines in git-rebase-todo directly it will suddenly stop working with > this change if they have rebase.missingCommitsCheck set to error. > > Having said all that we could decide that the existing error message is > enough and allow the user to skip re-editing the list if they really did > mean to remove those lines. It would be annoying to have to re-edit the > list when one had intended to delete those lines. > If we do not check the todo list after `exec' commands, patches 3 to 6 should be useless in this series and could be sent separately (I’m still interested in reducing useless round trips to the disk). I found a cleaner way to do that, without touching to sequencer_continue(). For the main feature of this series, I need to write tests for it, and then I’ll send it as a WIP series, once again. Cheers, Alban
