Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > Hi, > > On 2015-04-29 00:55, Phil Hord wrote: >> When rebase--interactive processes a task, it removes the item from >> the todo list and appends it to another list of executed tasks. If a >> pick (this includes squash and fixup) fails before the index has >> recorded the changes, take the corresponding item and put it on the todo >> list again. Otherwise, the changes introduced by the scheduled commit >> would be lost. >> >> That kind of decision is possible since the cherry-pick command >> signals why it failed to apply the changes of the given commit. Either >> the changes are recorded in the index using a conflict (return value 1) >> and rebase does not continue until they are resolved or the changes >> are not recorded in the index (return value neither 0 nor 1) and >> rebase has to try again with the same task. >> >> Add a test cases for regression testing to the "rebase-interactive" >> test suite. >> >> Signed-off-by: Fabian Ruch <bafain@xxxxxxxxx> >> Signed-off-by: Phil Hord <hordp@xxxxxxxxx> >> --- > > ACK. > > It would be even nicer to avoid removing the task from the `todo` list > until it has been performed correctly, of course, but I believe that > would require a much more invasive patch. So this here patch is fine > with me. Thanks, will queue. Aside from the "much more invasive" possibility, the patch makes me wonder if it would have been a better design to have a static "todo" with a "current" pointer as two state files. Then reschedule would have been just the matter of decrementing the number in "current", instead of "grab the last line of one file and prepend to the other file, and then lose the last line". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html