Re: [PATCH] rebase -i: redo tasks that die during cherry-pick
Phil Hord writes: > On Wed, Apr 29, 2015 at 1:15 PM, Junio C Hamano wrote: >> >> 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". > > That's an interesting idea. Changing it now would impact anyone who > now depends on the current todo/done behavior, and I imagine there > are many. Yeah, in case it wasn't clear, I was merely lamenting over water under the bridge, not seriously suggesting to break users to simplify our logic. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rebase -i: redo tasks that die during cherry-pick
On Wed, Apr 29, 2015 at 1:15 PM, Junio C Hamano wrote: > > 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". That's an interesting idea. Changing it now would impact anyone who now depends on the current todo/done behavior, and I imagine there are many. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rebase -i: redo tasks that die during cherry-pick
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 > Signed-off-by: Phil Hord > --- 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. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
