This patch centralizes passing HG_PENDING to external hook process
into '_exthook()'. To make in-memory changes visible to external hook
process, this patch does:
- write (or schedule to write) in-memory dirstate changes, and
- set HG_PENDING environment variable, if:
- a transaction is running, and
- there are in-memory changes to be visible
This patch tests some commands with some hooks, because transaction
activity of a same hook differs from each other ("---": "not tested").
======== ========= ========= ============
command preupdate precommit pretxncommit
======== ========= ========= ============
unshelve o --- ---
backout x --- ---
import --- o o
qrefresh --- x o
======== ========= ========= ============
Each hooks are examined separately to prevent in-memory changes from
being visible to external process accidentally by side effect of hooks
previously invoked.
When a user's repository is in an unfinished unshelve state and they choose to
abort, at a minimum, the repo should be out of that state. We've found
situations where the user could not leave the state unless manually deleting the
state file. This fix ensures that no matter what exception may be raised during
the abort, the shelved state file will be deleted, the user will be out of the
unshelve state and they can get their repository into a workable condition.
The current output for a failed merge with conflict markers looks something like:
merging foo
warning: conflicts during merge.
merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
merging bar
warning: conflicts during merge.
merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
We're going to change the way merges are done to perform all premerges before
all merges, so that the output above would look like:
merging foo
merging bar
warning: conflicts during merge.
merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
warning: conflicts during merge.
merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
The 'warning: conflicts during merge' line has no context, so is pretty
confusing.
This patch will change the future output to:
merging foo
merging bar
warning: conflicts while merging foo! (edit, then use 'hg resolve --mark')
warning: conflicts while merging bar! (edit, then use 'hg resolve --mark')
The hint on how to resolve the conflicts makes this a bit unwieldy, but solving
that is tricky because we already hint that people run 'hg resolve' to retry
unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker
based resolution.
Before this patch, 'bmstore.write()' always write in-memory bookmark
changes into '.hg/bookmarks' regardless of transaction activity.
If 'bmstore.write()' is invoked inside a transaction and it writes
changes into '.hg/bookmarks', then:
- original bookmarks aren't restored at failure of that transaction
This breaks "all or nothing" policy of the transaction.
BTW, "hg rollback" can restore bookmarks successfully even before
this patch, because original bookmarks are saved into
'.hg/journal.bookmarks' at the beginning of the transaction, and
it (actually renamed as '.hg/undo.bookmarks') is used by "hg
rollback".
- uncommitted bookmark changes are visible to other processes
This is a kind of "dirty read"
For example, 'rebase.rebase()' implies 'bmstore.write()', and it may
be executed inside the transaction of "hg unshelve". Then, intentional
aborting at the end of "hg unshelve" transaction doesn't restore
original bookmarks (this is obviously a bug).
This patch uses 'bmstore.recordchange()' instead of actual writing by
'bmstore._writerepo()', if any transaction is active
This patch also removes meaningless restoring bmstore explicitly at
the end of "hg shelve".
This patch doesn't choose fixing each 'bmstore.write()' callers as
like below, because writing similar code here and there is very
redundant.
before:
bmstore.write()
after:
tr = repo.currenttransaction()
if tr:
bmstore.recordchange(tr)
else:
bmstore.write()
Even though 'bmstore.write()' itself may have to be discarded by
putting bookmark operations into transaction scope, this patch chose
fixing it to implement "transactional dirstate" at first.
Before this patch, 'hg shelve -i' under non-interactive mode suggests
'use commit instead', and it obviously incorrect, because what user
wants to do isn't 'commit' but 'shelve'.
To omit incorrect 'commit' suggestion at 'hg shelve -i', this patch
specifies 'None' for 'cmdsuggest' argument of 'cmdutil.dorecord()'.
Before this patch, backups to be discarded are decided by steps below
at 'hg unshelve' or so:
1. list '(st_mtime, filename)' tuples of each backups up
2. sort list of these tuples, and
3. discard backups other than 'maxbackups' ones at the end of list
This doesn't work well in the case below:
- "sort by name" order differs from actual backup-ing order, and
- some of backups have same timestamp
For example, 'test-shelve.t' satisfies the former condition:
- 'default-01' < 'default-1' in "sort by name" order
- 'default-1' < 'default-01' in actual backup-ing order
Then, 'default-01' is discarded instead of 'default-1' unexpectedly,
if they have same timestamp. This failure appears occasionally,
because the most important condition "same timestamp" is timing
critical.
To avoid such unexpected discarding, this patch keeps old backups if
timestamp can't decide exact order of them.
Timestamp of the border backup (= the oldest one of recent
'maxbackups' ones) as 'bordermtime' is used to examine whether
timestamp can decide exact order of backups.
This will keep the backup directory from growing indefinitely. The number of
backups to keep can be set using the shelve.maxbackups config option (defaults
to 10 backups).
Instead of being deleted, shelve files are now moved into the .hg/shelve-backup
directory. This is designed similarly to how strip saves backups into
.ht/strip-backup. The goal is to prevent data loss especially when using
unshelve. There are cases in which a user can complete an unshelve but lose
some of the data that was shelved by, for example, resolving merge conflicts
incorrectly. Storing backups will allow the user to recover the data that was
shelved, at the expense of using more disk space over time.
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.
It's annoying having to specify --list and --patch/--stat when all you
really want to do is to dump a patch. This creates an explicit
--patch/--stat command that is executed if --list is not specified. It
ensures that 1) there is only one shelf name specified and 2) that the
shelf exists. Then it redirects to the original listcmd code.
While fixing issue4304: "record: allow editing new files" we introduced
changes in record/crecord. These changes need to be matched with changes in any
command using record. Shelve is one of these commands and the changes have
not been made for this release. Therefore, shelve -i should be an experimental
feature for this release.
When running on a slower systems (eg. MIPS buildd), the age of the
shelf can be 10 seconds or more, resulting in the output alignment
changing and thus a test failure. This patch makes the spacing be
matched more leniently.
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
In the body of the loop in trydiff(), there are conditions like:
addedset or (f in modifiedset and to is None)
The second half of that expression is to account for the fact that
merge-in additions appear as additions. By instead fixing up the sets
of modified and added files to compensate for this fact, we can
simplify the body of the loop. It also fixes one case where the
addedset was checked without the additional check (the "have we
already reported a copy above?" case in the code, also see fixed test
case).
The similar condition with 'removedset' in it seems to have served no
purpose even before this change, so it could have been simplified even
before.
Show status messages while rebasing, similar to what graft do:
rebasing 12:2647734878ef "fork" (tip)
This gives more context for the user when resolving conflicts.
The obsolete._enabled flag has become a config option. This updates all but one
of the tests to use the minimal number of flags necessary for them to pass. For
most tests this is just 'createmarkers', for a couple tests it's
'allowunstable', and for even fewer it's 'exchange'.
This is preparation for removing open-coded rebase/graft operations.
As a side-effect, this exposes proper renames in the working copy when
there are conflicts, which shows up in test-shelve.t.
When unshelving and facing a conflict, if we resolve all conflicts in
favour of the committed changes instead of the shelved changes, then
the ensuing implicit rebase is a no-op. That is, there is nothing to
rebase. In this case, there are no extra intermediate shelve commits
to strip either. Prior to this change, the commit being unshelved to
would be marked for destruction in a rather catastrophic way.
The relevant part of the test case failed as follows:
$ hg unshelve -c
unshelve of 'default' complete
$ hg diff
warning: ignoring unknown working parent 33f7f61e6c5e!
diff --git a/a/a b/a/a
new file mode 100644
--- /dev/null
b/a/a
@@ -0,0 1,3 @@
a
c
x
$ hg status
warning: ignoring unknown working parent 33f7f61e6c5e!
M a/a
? a/a.orig
? foo/foo
$ hg summary
warning: ignoring unknown working parent 33f7f61e6c5e!
parent: -1:000000000000 (no revision checked out)
branch: default
commit: 1 modified, 2 unknown (new branch head)
update: 4 new changesets (update)
With this change, this test case now passes.
Tracking clean files is the simplest way to be able to reports files that need
no changes. So we explicitly retrieve them.
This fixes a couple of test outputs where the lack of changes was not reported.
We already have a ":" after the user name to denote the start of the
description. The current usage of quotes around the description is
problematic as the truncation to 80 chars is likely to drop the
closing quote. This may confuse syntax coloration in some editors.
This broke some internal automation that was quite reasonably checking for
unresolved files as a way to determine whether a merge happened cleanly. We
still abort for resolve --mark etc.
Changes rebase conflict markers to say 'source' and 'dest' instead of
'local' and 'other'. This ends up looking like:
one
<<<<<<< dest: a3e5c7fd master - bob: "A commit to master"
master
=======
mine
>>>>>>> source: c7fda3e5 - durham: "A commit to my feature branch"
three
Adds a conflict marker formatter that can produce custom conflict marker
descriptions. It can be set via ui.mergemarkertemplate. The old behavior
can be used still by setting ui.mergemarkers=basic.
The default format is similar to:
{node|short} {tag} {branch} {bookmarks} - {author}: "{desc|firstline}"
And renders as:
contextblahblah
<<<<<<< local: c7fdd7ce4652 - durham: "Fix broken stuff in my feature branch"
line from my changes
=======
line from the other changes
>>>>>>> other: a3e55d7f4d38 master - sid0: "This is a commit to master th...
morecontextblahblah
The recently introduced message was:
no unresolved files; you may continue your unfinished operation
This had three problems:
- looks a bit like an error message because it's not saying "we've
just resolved the last file"
- refers to "unfinished operation", which won't be the case with
"update" or "merge"
- introduces semicolons to error messages, which is stylistically
questionable
I've simplified this to:
no more unresolved files
In the future, if we want to prompt someone to continue a particular operation, we should use
a hint style:
no more unresolved files
(use 'hg graft --continue' to finish grafting)
When using resolve, users often have to consult with the output of |hg
resolve -l| to see if any unresolved files remain. This step is tedious
and adds overhead to resolving.
This patch will notify a user if there are no unresolved files remaining
after executing |hg resolve|::
no unresolved files; you may continue your unfinished operation
The patch stops short of telling the user exactly what command should be
executed to continue the unfinished operation. That is because this
information is not currently captured anywhere. This would make a
compelling follow-up feature.
The resolve command is only relevant when mergestate is present.
This patch will make resolve abort when no mergestate is present.
This change will let people know when they are using resolve when they
shouldn't be. This change will let people know when their use of resolve
doesn't do anything.
Previously, |hg resolve -m| would allow mergestate to be created. This
patch now forbids that. Strictly speaking, this is backwards
incompatible. The author of this patch believes creating mergestate via
resolve doesn't make much sense and this side-effect was unintended.
msys (on windows) converets '-R bundle:.XX/XX' to '-R bundle:;.XX/XX'. Avoid
this by writing '-R bundle://.XX/XX'. This is used more often than the
alternative work arounds like '-Rbundle://.XX/XX' or '-R bundle:Y/../.XX/XX'.
It was hard for the user to know what was going on when unshelving - especially
if the user had to resolve conflicts and thus got to see the intermediate
states.
Seeing that pending changes was gone could scare the user, make him panic, and
do stuff that really made him lose data.
Merging (both when rebasing and with pending changes) also requires some
understanding of where in the process you are and what you are merging.
To help the user we now show a couple of status messages (when relevant):
temporarily committing pending changes (restore with 'hg unshelve --abort')
rebasing shelved changes
unshelve was quite verbose and it was hard for a user to follow what really was
going on. It ended up saying 'added 1 changesets' ... but the user just
expected and got pending changes and never saw any changeset.
The use of bundles is an implementation detail that we don't have to leak here.
Pulling is quite verbose, optimized for pulling many changesets from remote
repos - that is not the case here.
Instead, set the quiet flag when pulling the bundle - not only when temporarily
committing pending changes.
The 'finally' restore of ui.quiet is moved to the outer try/finally used for
locking.
The shelved changes _could_ perhaps be amended to the parent changeset but it
_is_ not the parent changeset. Using the description from the parent changeset
is thus wrong and confusing.
Instead, add a 'changes to' prefix.
when evolve is enabled and a hidden obsolete changeset exists
in the repository, the strip during unshelve will fail due to
filtered revs. we use an unfiltered repository like to
repair.strip to strip the proper nodes.
This is arguably a workaround, a better fix may be in the repo to
ensure that it won't list a file 'modified' unless there is a file
context for the previous version.
Before this patch, commit is allowed even while unshelve is in
progress.
In the other hand, "hg unshelve --abort" and "hg unshelve --continue"
check whether parent revisions of the working directory have changed
or not since last "hg unshelve", and abort without clearing state for
unshelve in progress if they have.
This causes that accidental commit makes clearing state for unshelve
difficult in ordinary ways.
This patch disallows commit while unshelve is in progress for
consistency.
Previously, shelve used merge to unshelve things. This meant that if you shelved
changes on one branch, then unshelved on another, all the changes from the first
branch would be present in the second branch, and not just the shelved changes.
The fix is to use rebase to pick the shelve commit off the original branch and
place it on top of the new branch. This means only the shelved changes are
brought across.
This has the side effect of fixing several other issues in shelve:
- you can now unshelve into a file that already has pending changes
- unshelve a mv/cp now has the correct dirstate value (A instead of M)
- you can now unshelve to an ancestor of the shelve
- unshelve now no longer deletes untracked .orig files
Updates tests and adds a new one to cover the issue. The test changes fall into
a few categories:
- I removed some excess output
- The --continue/--abort state is a little different, so the parents and
dirstate needed updating
- Removed some untracked files at certain points that cluttered the output
