--edit-plan was completely broken from the command line because it used an old
api that was not updated (it would crash with a stack trace). Let's update it
and add tests to catch this.
Commit 960f8ca79ab1 broke histedit's rollup by causing it to open the editor.
Turns out I missed a spot where the rollup option was read.
This fixes that and adjusts the test to catch this case.
The existing state serialization format assumed the rule line consisted of an
action and a hash. In our external extension that adds 'exec' this is not the
case (there is no hash, just the shell command). So let's change the format to
be more generic with just an action and a remainder, and the various commands
can handle it as they wish.
Flagged for stable since we want to get this format tweak in before the new
format goes live in the release.
Previously the fold action would inspect it's class to figure out if it was a
rollup or not. This was hacky. Now that finishfold is inside the fold class,
let's modify it to check a function (which roll can override) to determine if it
should be prompting for a commit message.
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.
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.
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.
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.
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.
It's possible for the user to delete some of the commits they started with
during a histedit, and aborting the histedit doesn't bring them back. Let's
store a backup bundle so we can always recover the stack of commits from before
they began.
We were trying to prevent strips of important nodes during histedit,
but the check was actually comparing the short hashes in the rules to
the exact value the user typed in, so it only ever worked if the user
typed a 12 character hash.
In a previous commit we removed the extra histedit object instance being
constructed in --continue and --abort. The new --edit-todo missed this fix
though (which means the state object it produces doesn't have the locks on it).
It's not breaking anything now, but let's go ahead and clean that up before we
forget.
Before this change hg help histedit would use the default variable label:
--commands VALUE
...
-r --rev VALUE [+]
With this change the text will be in the usual help text style and a bit more
explanatory:
--commands FILE
...
-r --rev REV [+]
The rest of help messages for command arguments are simple phrases without any
ending punctuation, so having this text be a complete sentence didn't really
fit.
Since many users are using terminals wider than 80 chars there should be an
option to have longer lines in histedit editor.
Even if the summary line is shorter than 80 chars after adding action line
prefixes (like "pick 7c2fd3b9020c") it doesn't fit there anymore. Setting
it to for example 110 would be a nice option to have.
Previously, the histedit state object was being recreated during continue/abort.
This meant that the locks that were held on the original state object were not
available to actions, which meant actions could not release the lock on the
repository (like an 'exec' action would need to do).
This affected our internal extension that added the 'exec' action.
Currently, if the node no longer exists, the state object fails to load
and pukes with an exception. Changing the state object to only store the
node allows callers to handle these cases. For instance, in
bootstrapcontinue we can now detect that the node doesn't exist and exit
gracefully.
The alternative is to have the state object store something like None
when the node doesn't exist, but then outside callers won't be able to
access the old node for recovery (unless we store both the node and the
ctx, but why bother).
More importantly it allows us to detect this case when doing hg histedit
--abort. Currently this situation results in both --continue and
--abort being broken and the user has to rm .hg/histedit-state to unwedge
their repo.
(description by Durham Goode)
During histedit we don't want user to do any operation resulting in
stripping nodes needed to continue history editing. This patch
wraps the strip function to detect such situations.
Adds a configuration setting for allowing users to specify the default behavior
of 'hg histedit' without arguments. This saves users from having to manually
figure out the bottom commit or a complicated revset. My current revset of
choice is "only(.) & draft() - ::merge()"
The commits that histedit can work with is usually quite limited, so if this
feature ends up working well, we may want to consider making "only(.) & draft()
- ::merge()" the default behavior for everyone.
Previously histedit only stored the short version of the rule nodes in the
state. This meant that later we couldn't resolve a rule node to its full
form if the commit had been deleted from the repo.
Let's store the full form from the beginning.
Read the state in histeditstate. This allows us to correctly update
internal variables when necessary without having to recreate a new
state. When we read a state in _histedit state while we will already
have state passed from histedit(), we can read the state in place
and don't have to merge two histeditstates.
The histedit code often expects a context. However histedit hands
around the tuple for the serialization and therefore hand over a
parentctxnode. This leads to code having to return a context based
on the parentctxnode. We let the state only return a context but
correctly serialize and deserialze to a node.
Add an histeditstate class that is intended to hold the current
state. This allows us encapsulate the state and avoids passing
around a tuple which is based on the serialization format. In
particular this will give actions more control over the state and
allow external sources to have more control of histedits behavior,
e.g. an external implementation of x/exec.
The basic obsolete option is allowing the creation of obsolete markers. This
does not enable other features, such as allowing unstable commits or exchanging
obsolete markers.
