Wed, 21 Mar 2018 11:01:19 -0700 rebase: store rebase state after each commit
Martin von Zweigbergk <martinvonz@google.com> [Wed, 21 Mar 2018 11:01:19 -0700] rev 37032
rebase: store rebase state after each commit 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
Wed, 21 Mar 2018 10:46:00 -0700 rebase: register status file generator only once when using single transaction
Martin von Zweigbergk <martinvonz@google.com> [Wed, 21 Mar 2018 10:46:00 -0700] rev 37031
rebase: register status file generator only once when using single transaction rebase.storestatus() behaved differently depending on whether a transaction is passed to it. If a transaction is passed, it registers a "file generator" that runs when the transaction commits. If no transaction was passed, it writes the rebase state immediately. This imprecise timing of the writing makes it hard to reason about, so let's make it more explicit which behavior we're getting by checking if we have a transaction before calling it. For the single-transaction case, move the call to storestatus(tr) early and do it only once since it's only going to write the file (at most) once anyway. Differential Revision: https://phab.mercurial-scm.org/D2912
Sun, 18 Mar 2018 22:26:23 -0700 tests: add some more tests to test-rebase-collapse.t
Martin von Zweigbergk <martinvonz@google.com> [Sun, 18 Mar 2018 22:26:23 -0700] rev 37030
tests: add some more tests to test-rebase-collapse.t Some of these are currently broken. Differential Revision: https://phab.mercurial-scm.org/D2911
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip