Editing the history only is possible when the working dir is a descendant of
the revisions to edit. When this happens explain it by writing
abort: %s is not an ancestor of working directory
If the binary hash of the parent node guessed via --outgoing happened
to contain a special revset character (":" was specified in the bug),
the revset parser would abort. Hexlifying the node before passing it
to the revsingle call should fix that.
Before this changeset, histedit created all new changesets according
phases.new-commit option without any regards for the phases of the original
changesets.
This changeset fix that using the phase of rewritten changeset to decide the
phase of the resulting changeset. In case of reordering or folding, we keep
secret item secret as it seems the safer path.
temporary commit creation are not affected. They are head only and stripped at
the end of the histedit.
As for the resolution of issue3681 (obsolescence cycle prevention), we do not
handle changesets created by edit command.
Have histedit record the hex of the original changeset as already done by:
- graft
- commit --amend
- rebase
My main motivation for adding this is to prevent the creation of obsolescence cycle
(see issue3681).
Note that commit created during edit are not affected yet.
Later commits add two important items to histedit:
- Obsolescence cycle prevention
- Proper phase conservation
Those logics must be applied to all simple operations (pick, edit, mess) and
will require verbose code.
So we introduce a new function that will provide an entry point for this new.
logic.
The function build a closure to have a clear distinction between commit
arguments and data provided to the function to fulfil its logic.
In the context of help document on which this patch focuses, the
example repository, which is source of cloning, should be already
histedit-ed, and contain only 3 revisions (rev # 0 to 2). So, not 3,
but 4 revisions should be added to the destination repository of
cloning, if it contains 7 revisions (rev # 0 to 6).
This patch also adds modifier "histedit-ed" to "example repository",
to make context clear.
There is no '633536316234' revision in the example repository. It
should be 'c561b4e977df', according to the revisions in it and
explanation in help document.
Obsolescence markers can represent this situation just fine. Rewritten
revisions are marked as precursors of the ones creates by
histedit. Unaffected descendants become "unstable".
If obsolescence is not enabled we keep the current behavior of
aborting. This new behavior only applies when obsolete is
enabled and is subject to future discussion and changes.
Bookmarks persistence still showed a fair amount of its legacy as a
monkeypatching extension. This encapsulates all bookmarks
serialization and parsing in a single class, and offers a single
location where other bookmarks storage engines can be substituted
in. As a result, many files no longer import the bookmarks module,
which strikes me as an encapsulation win.
This doesn't do anything to the current bookmark state yet, but I'm
hoping put that in the bmstore class as well.
We do not want hidden revision to block histedit. They are already "dead"
and we do not care about dead orphans. see similar changeset 40db49347807 for
rebase.
When the obsolete feature is enabled, histedit creates obsolescence marker
instead of stripping replaced changesets.
For now, we keep stripping temporary nodes created along the way.
This changeset rewrites the change tracking logic of histedit to record every
operation it does. Tracked operations record the full list of "old" node that
will eventually be removed to the list of new nodes that replace it. Operations
on temporary nodes are tracked too. Dropped changesets are also recorded as an
"old" node replacement by nothing. This logic is similar to the obsolescence
marker one and will be used for this purpose in later commit.
This new logic implies a big amount of change in the histedit code base.
histedit action functions now always return a tuple of
(new-ctx, [list of rewriting operations])
The old `created`, `replaced` and `tmpnodes` are no longer returned and stored
during histedit operation. When such information is necessary it is computed
from the replacement graph. This computation is done in the `processreplacement`
function.
The `replacemap` is also dropped. It is computed at the end of the command from the
graph. The `bootstrapcontinue` methods are altered to compute this different kind of
information.
This new mechanism requires much less information to be written on disk.
Note:
This changes allows a more accurate bookmark movement. bookmark on dropped
changeset are now move of their parent (or replacement of their parent)
instead of their children.
This fix issue3582
We are now checking for any changesets between the previous `parentctx` and the
current working directory parent. If the current working directory parent is
inconsistent, we abort.
This change is useful as it simplifies the --continue process, easing upcoming
changes.
While working on this changeset, I spotted an unhandled corner case. This corner
case is now documented and have an appropriate issue in the tracker (issue3655).
However, the corner case is still unhandled. handling this test case would
required some additional work:
- actually decide what the proper behavior should be:
- change content of "histedit-state" to add missing data necessary to detect
the situation
- add proper testcase,
But leaving the case unhandled is "okay":
- this is not a regression,
- this is not the purpose of the current series,
- the freeze was near and I had more critical stuff to attend to,
- this is a simple but non trivial, (see above)
When histedit "continue", there is several complicated logic to apply in order to
detect intermediate changeset and concluded pending operation.
This changeset extract this logic in a dedicated function to lighten the main
one. No alteration to the logic is done.
Create a function dedicated to stripping a group of node. All existing
duplicated code is replaced by call to this function.
This new function take care of stripping known and relevant node only.
The old and fragile patching logic is replaced by smart merges (as rebase and
graft do). This should prevents some conflicts and smoother human resolution.
For this purpose the "foldchanges" function is renamed to "applychanges" and
handle a single revision only.
Update the folding code to works in memory instead of applying patches on the
working directory. This is cleaner, faster and prepare the removal of the whole
patching logic.
This new collapse function will probably move into core sooner or later. A lot
of other rewriting operation may benefit from it.
This patch is the first step towards a refactoring of the histedit
extension to use underlying graft machinery instead of diff/patch as
discussed in issue3527. Replacing diff/patch with graft is necessary
to fix, for example, issue3582.
"i18n.gettext()" invocation for "editcomment" itself should have
little impact for whole initialization cost of histedit, because it is
already invoked for initialization of the command table entry.
'\n\n' has to be added to the text being edited separately from
"editcomment", because leading 'line feed' characters are not exported
to "hg.pot" file correctly.
Before this patch, updating statistics line appears at the bottom of
the examples describing rules to edit history.
But such line never appear in the file describing rules while
histedit-ing, so this patch removes that line from the examples.
When running the following actions:
pick 617f94f13c0f 1 +4
drop 888f9082bf99 2 +5
fold 251d831eeec5 3 +6
if the fold fails, is fixed by the user with a new changeset, --continue
will ignore the new revision when generating the fold changelog. This
was caused by --continue detecting new changesets as descendants of the
parent not descendants of changesets in the initial list. In this case,
dropped changesets must be ignored.
Even with the computation fixed, the 'newchildren' list was always
emptied by the filtering loop and passed empty to finishfold().
Note that changesets dropped and recreated identically will still be
missed. This probably cannot be solved but is unlikely to happen.
Other things, like 'newchildren' having multiple heads, should be
checked as well.