Sat, 04 Apr 2015 02:12:24 -0700 histedit: move finishfold into fold class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 02:12:24 -0700] rev 24772
histedit: move finishfold into fold class Let's move the finishfold function into the fold class so we can modify it from the roll class more easily.
Sat, 04 Apr 2015 02:03:27 -0700 histedit: convert fold/roll actions into a class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 02:03:27 -0700] rev 24771
histedit: convert fold/roll actions into a class This converts the fold/roll actions into a histeditclass instance, as part of an ongoing effort to refactor histedit for maintainability and robustness. The tests changed for two reasons: 1) We get a new 'empty changeset' warning because we now warn more consistently between normal histedit and --continue about commits disappearing. 2) Previously we were not putting the histedit-source extra field on the temporary fold commit during normal runs, but we were on --continue runs. By unifying these code paths we now consistently put histedit-source on the temporary fold commit, which changes some of the hashes in the backup bundles.
Sat, 04 Apr 2015 01:00:51 -0700 histedit: convert edit action into a class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 01:00:51 -0700] rev 24770
histedit: convert edit action into a class This converts the edit action into a histeditclass instance, as part of an ongoing effort to refactor histedit for maintainability and robustness.
Sat, 04 Apr 2015 00:42:32 -0700 histedit: convert message action into a class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 00:42:32 -0700] rev 24769
histedit: convert message action into a class This converts the message action into a histeditclass instance, as part of an ongoing effort to refactor histedit for maintainability and robustness.
Sat, 04 Apr 2015 00:30:01 -0700 histedit: convert drop action into a class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 00:30:01 -0700] rev 24768
histedit: convert drop action into a class This converts the drop action into a histeditclass instance, as part of an ongoing effort to refactor histedit for maintainability and robustness.
Sat, 04 Apr 2015 11:39:08 -0700 histedit: convert pick action into a class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 11:39:08 -0700] rev 24767
histedit: convert pick action into a class This converts the pick action into a histeditclass instance, as part of an ongoing effort to refactor histedit for maintainability and robustness. The test output changed because previously pick would only report the commit disappearing if there were no merge conflicts. Now that we've unified the normal and the --continue flows, they act the same and we get the warning even after --continue.
Sat, 04 Apr 2015 11:37:08 -0700 histedit: integrate action class into flow
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 11:37:08 -0700] rev 24766
histedit: integrate action class into flow This takes the newly added histeditaction class and integrates it into the histedit run and bootstrapcontinue logic. No actions implement the class yet, but they will be add in upcoming patches.
Sat, 04 Apr 2015 11:34:53 -0700 histedit: add a new histeditaction class
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 11:34:53 -0700] rev 24765
histedit: add a new histeditaction class This adds a new class called histeditaction. It represents a single action in a histedit plan. Future patches will integrate it into the histedit flow, then convert each existing action in to the class form one by one. This is part of a larger refactor aimed at increasing histedit robustness, maintainability, and extensibility.
Sat, 04 Apr 2015 01:00:05 -0700 histedit: allow histedit --continue when not on a descendant (BC)
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 01:00:05 -0700] rev 24764
histedit: allow histedit --continue when not on a descendant (BC) Previously we would not allow --continue if the current working copy parent was not a descendant of the commit produced by the previous histedit step. There's nothing really blocking us from continuing the histedit in this situation, so let's stop aborting in this case. This is technically a BC change, but it is making things more forgiving so I think it's ok. In the future we will likely add an 'exec' action to histedit, which means the user can do whatever they want during the middle of a histedit (like perhaps calling 'hg update'), which means we'll need to support this case eventually anyway.
Thu, 16 Apr 2015 11:59:36 -0400 tags: explicitly log which tags cache file is being written
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Apr 2015 11:59:36 -0400] rev 24763
tags: explicitly log which tags cache file is being written We now have multiple tags cache files. Record exactly which file is being written. This should help aid debugging into performance issues with any single filter.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip