Skip to content
  • Martin von Zweigbergk's avatar
    rebase: store rebase state after each commit · 98663bed146e
    Martin von Zweigbergk authored
    Before this patch, we stored the rebase state early in the processing
    of a node, before we updated the rebase state to indicate that the
    node was processed. This meant that we could redo the working copy
    merge and run into conflicts. However, this only happened in the
    --collapse case if the rebase was interrupted while editing the final
    commit message; in the case earlier interruptions, we would instead
    detect the in-process revision by finding two dirstate parents.
    
    This patch moves the writing of the rebase state to after we have
    completed the revision completely, and, importantly, after we have
    updated the rebase state to mark it done. This means we'll realize
    that all nodes have been rebased in the case mentioned above of
    editing the final commit message of a --collapse. See change to test
    case.
    
    I also moved the writing outside of the large if/elif block in
    _rebasenode(). This shouldn't matter much, but seems cleaner. One
    observable effect is if rebase was interrupted just after ignoring an
    obsolete node ("not rebasing ####, already in destination"), we used
    to come up with the same decision after --continue too, but after this
    patch we'll instead say "already rebased ###". This seems more
    consistent, since that's what we would do with obsolete nodes that had
    been marked done earlier in the process (not only just before the
    interruption).
    
    Differential Revision: https://phab.mercurial-scm.org/D2913
    98663bed146e