The default behaviour to forbid this makes a lot of sense for novice users
because it's safeguarding them from dangerous behavior but making it
configurable will be apprieciated by power users in at least one big
organization.
It allows an user to look an histedit rules from declarative perspective and
make the rules reflect the state after histedit. If we can move lines t move
commits why can't we drop lines to drop commits?
Let's put this behind config knob and inform users about this feature the very
moment they are trying to use it so they can choose desired behaviour.
Previously, `hg histedit` required a revision argument specifying which
revision to use as the base for the current histedit operation. There
was an undocumented and experimental "histedit.defaultrev" option that
supported defining a single revision to be used if no argument is
passed.
Mercurial knows what changesets can be edited. And in most scenarios,
people want to edit this history of everything on the current head that
is rewritable. Making histedit do this by default and not require
an explicit argument or additional configuration is a major usability
win and will enable more people to use histedit.
This patch changes the behavior of the experimental and undocumented
"histedit.defaultrev" config option to select an appropriate base
revision by default. Comprehensive tests exercising the edge cases
in the new, somewhat complicated default revset have been added.
Surprisingly, no tests broke. I guess we were never testing the
behavior with no ANCESTOR argument (it used to fail with
"abort: histedit requires exactly one ancestor revision"). The new
behavior is much more user friendly.
The functionality for choosing the default base revision has been
moved to destutil.py, where it can easily be modified by extensions.
This change is replacing most of state.rules uses with state.actions
uses. The next change will change histeditstate class to actually
uses state actions.
the format of rules that we store in state file format is different from the rule
format that we present to users. We need a way of dumping action to state file.
To make histedit action objects responsible for understanding
the format of their action lines we are adding a torule method
which for a histedit action will return a string which can be
saved in histedit state or shown in text editor when editing the
plan.
This commits splits the parsing of the histedit rule from its semantic analysis.
It's necessary because sometimes we want to do first without doing the former (reading the
histedit state).
This decorator will is allowing us to move the registering the action
in actiontable closer to the action code. Also it is storing the
verb inside histedit action so the action is aware of the verb
needed to trigger it.
I want to refactor histedit to use action objects instead of (verb, rest)
pairs whenever possible. At the end of this series I want the rules to
be translated into action objects when reading state and translated back
when writing state. All histedit internals should use action objects instead
of state rules.
To migrate histedti internals sequentially I'm introducing the state.actions
property to translate rules on the fly so we can use both state.actions and
state.rules until refactoring is done.
Users may spend a lot of effort writing histedit rules,
getting an abort without being told they can recover their work
is very frustrating.
Avoid that by telling them where to find their work.
Used a class as a namespace, and then wired up a classmethod to return
all known constraints. I'm mostly happy with this, even though it's
kind of weird for hg.
This is a first (very simple) version of the histedit base action.
It works well in common usecases like rebasing the whole stack and
spliting the stack.
I don't see any obvious edge cases - but probably there is more than one.
That's why I want to keep it behind experimental.histeditng config knob
for now. I think on knob for all new histedit behaviors is better because
we will test all of them together and testers will need to turn it on only
once to get all new nice things.
For the future 'base' action in histedit we need a verification
constraint which will not allow using this action with changes
that are currently edited.
Before we can add a 'base' action to histedit need to change verification
so that action can specify which steps of verification should run for it.
Also it's everything we need for the exec and stop actions implementation.
I thought about baking verification into each histedit action (so each
of them is responsible for verifying its constraints) but it felt wrong
because:
- every action would need to know its context (eg. the list of all other
actions)
- a lot of duplicated work will be added - each action will iterate through
all others
- the steps of the verification would need to be extracted and named anyway
in order to be reused
The verifyrules function grows too big now. I plan to refator it in one of
the next series.
Before this patch we were using the old api bookmarks.write, this patches
replaces its usage by bookmarks.recordchange, the new api to record bookmark
changes.
Back in June we made histedit use obsolete markers to cleanup when possible.
This was rolled back as part of bb3db0db4037 (which should have only rolled back
the --abort stuff, but rolled back everything). This caused a nasty bug when
used in conjuction with the inhibit+directaccess extensions where histedit would
leave old nodes around even after they had been squashed away.
The root of the problem is that we first clean up old nodes, and then we clean
up temp nodes. In the first pass, when we obsoleted old nodes, some would become
unobsolete because they had temp nodes on top of them, thus making them stick
around even after the histedit finished.
The fix is to A) move the temp node cleanup to be before the old node cleanup
(since they are topological on top of the old nodes), and B) use obsolete
markers instead of stripping.
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
confused about that and gives all the credit to 'util' instead of the
hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
give back to 'error' the respect it deserves. And screw that 'util' poser.
For great justice.
When an user aborts a histedit, many things could go wrong. At a minimum, after
a histedit abort failure, their repository should be out of that state. We've
found situations where the user could not exit the histedit state without
manually deleting the histedit state file. This patch ensures that if any
exception happens during an abort, the histedit statefile will be deleted so
that users are out of the histedit state and can at least manually get the repo
back to a workable condition.
When the histeditstate class instance has it's clear() method called, there is
nothing to check to see if the state file exists before deleting it. It may not
exist, which would create an exception. This patch allows clear to be called at
any time.
This will be needed for the following patch.
If a histedit is progress, the 'histedit-state' file should exist. The patch
implements a convenience function to do check if a histedit is in progress.
This method will be use in next patch in the series.
This was the first ever feature request for histedit, originally filed
back on April 4, 2009. Finally fixed.
In the future we'll probably want to make it possible for other
preprocessing steps to be added to the list, but for now we're
skipping that because it's unclear what the API should look like
without a proposed consumer.
