This is suboptimal as the user still has to explicitly cancel the
histedit afterwards, but it prevents the immediate problem.
histedit should probably implicitly do 'hg histedit --abort' if a
util.Abort is raised internally.
Durham and I agree that it's a bug you can fold into a change that's
not listed in the histedited set, so we'll follow this up with a
change that prevents folds as the first edit step.
The phase of the pending commit depends on the parent of the working directory
and on the phases.newcommit configuration.
First, this information rather depend on the commit line which describe the
pending commit.
Then, we only want to be advertised when the pending phase is going to be higher
than the default new commit phase.
So the format will change from
$ hg summary
parent: 2:ab91dfabc5ad
foo
parent: 3:24f1031ad244 tip
bar
branch: default
commit: 1 modified, 1 unknown, 1 unresolved (merge)
update: (current)
phases: 1 secret (secret)
to
parent: 2:ab91dfabc5ad
foo
parent: 3:24f1031ad244 tip
bar
branch: default
commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret)
update: (current)
phases: 1 secret
The number of draft and secret changesets are currently not summarized.
This is an important information because the number of drafts give some rough
idea of the number of outgoing changesets in typical workflows, without needing
to probe a remote repository. And a non-zero number of secrets means that
those changeset will not be pushed.
If the repository is "dirty" - some draft or secret changesets exists - then
summary will display a line like:
phases: X draft, Y secret (public)
The phase in parenthesis corresponds to the highest phase of the parents of
the working directory, i.e. the current phase.
By default, the line is not printed if the repository is "clean" - all
changesets are public - but if verbose is activated, it will display:
phases: (public)
On the other hand, nothing will be printed if quiet is in action.
A few tests have been added in test-phases.t to cover the -v and -q cases.
test-histedit-edit was broken because it relied on the HGEDITOR script being
executable. Instead, lets just execute 'sh' and pass it the script to run. This
seems to be the pattern followed in other tests.
--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.
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.
This was accidentally fixed by other work, but given that it's been
broken in the past, I'd like to have a test defending us against
regressions in this area, especially as we add more functionality to
histedit.
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.
Previously, a backup bundle could overwrite an existing bundle and cause user
data loss. For instance, if you have A<-B<-C and strip B, it produces backup
bundle B-backup.hg. If you then hg pull -r B B-backup.hg and strip it again, it
overwrites the existing B-backup.hg and C is lost.
The fix is to add a hash of all the nodes inside that bundle to the filename.
Fixed up existing tests and added a new test in test-strip.t
This omits (redundant) adding "\n' to "message", because:
- empty line is inserted by "commitforceeditor", if editor is invoked
- tail white-spaces are stripped at storing into chaneglog, otherwise
This patch also enhances "test-histedit-edit.t", because "hg histedit"
hasn't been explicitly tested around editor invocation and
"--continue" option.
Before this patch, "hg histedit" for "message" uses "ui.edit()" for
commit message editing.
It shows original commit message, but not detail about the target
revision: status of each modified/added/removed files, for example.
This patch uses the editor gotten by "getcommiteditor()" instead of
"ui.edit()" for "message"
In "test-histedit-edit.t", this patch omits "fixbundle" invocation,
because it prevents from confirming the "HG: added f" line in commit
message by filtering " added " lines.
Omiting "fixbundle" invocation causes that the exit code of "hg
histedit" appears as one of command line: in this case, "hg histedit"
is aborted by (expected) exception raising.
Before this patch, "message" action of "hg histedit" uses "ui.edit()"
explicitly to get commit message edited manually.
This requires explicit "localrepository.savecommitmessage()"
invocation to save edited commit message into ".hg/last-message.txt",
because unexpected exception raising may abort command execution
before saving it in "localrepository.commit()".
This patch uses "editor" argument of "localrepository.commit()"
instead of explicit "ui.edit()" invocation for "message" action of "hg
histedit"
"localrepository.commit()" will invoke "editor()" function newly added
in this patch, and save edited commit message into ".hg/last-message.txt"
automatically.
Before this patch, manually edited commit message for "message"
command in histedit-ing is not saved into ".hg/last-message.txt" until
it is saved by "localrepository.savecommitmessage()" in
"localrepository.commit()".
This may lose such commit message, if unexpected exception is raised.
This patch saves manually edited commit message for "message" comand
in histedit-ing into ".hg/last-message.txt" just after user editing.
This is the simplest implementation to fix on stable. Editing and
saving commit message should be centralized into the framework of
"localrepository.commit()" with "editor" argument in the future.
This patch uses repository wrapping class for exception raising before
saving commit message in "localrepository.commit()" easily and
certainly, because such exception requires corner case condition.
The tests contain a couple corner cases where workarounds are now
required. Strictly speaking, these are behavior regressions, but of an
extremely obscure and marginal sort. Commits or updates in the middle
of a histedit would have almost always been fairly serious user error.
This is simpler than temporary file version. There some minor test
changes since commit messages are no longer modifed. There is still
some tests using --commands with a real file.
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.
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)
