If an emergency comes in while you're in the middle of an experimental
change, it can be useful to shelve not just files hg already tracks but
also your unknown files while you handle the emergency. This is
especially true if you have hooks intended to prevent you from
forgetting to add new code before you push.
Teach "hg shelve" to optionally shelve unknown files, not just tracked
files. This is functionally similar to --addremove, but with two
differences:
1) Deleted files are not removed.
2) Files added during shelve creation are tracked in extra so that they
can be forgotten by "hg unshelve".
When unshelving, we take care to only forget files if they've been
created during the unshelve operation; if you add a file that's being
tracked in a shelve as an unknown file, it should not become unknown
again when the shelve is unshelved.
If detailed conflict markers are enabled and the closing quote gets truncated,
editors will often screw syntax highlighting up from that point because they'll
see an opening quote and think it's the beginning of a string.
In tests, the hashes change because the commit messages of the shelved bundles
also change.
These are related to differences in how missing files and network connection
failures are displayed. I opted to combine the strings in one line instead of
using '#if windows' blocks around entire commands in order to avoid future
changes being accidentally missed in the Windows sections. Globbing away the
entire output seemed wrong, as it could mask other failures.
The raw messages involved are:
Linux Windows
"* not known" <-> "getaddrinfo failed"
"Connection refused" <-> "No connection could be made because the
target machine actively refused it"
"No such file or directory" <-> "The system cannot find the file specified"
Issue 4941 indicates that NetBSD has yet another string for "* not known".
Also, the histedit test shows that the missing file is printed first on Windows,
last on Linux. That is controlled in windows.py:posixfile if we care to change
it.
4bc805f938a0 made 'bmstore.write()' transaction sensitive, to restore
original bookmarks correctly at failure of a transaction.
For example, shelve and unshelve imply steps below:
before 4bc805f938a0:
1. move active bookmark forward at internal rebasing
2. 'bmstore.write()' writes updated ones into .hg/bookmarks
3. rollback transaction to remove internal commits
4. restore updated bookmarks manually
after 4bc805f938a0:
1. move active bookmark forward at internal rebasing
2. 'bmstore.write()' doesn't write updated ones into .hg/bookmarks
(these are written into .hg/bookmarks.pending, if external hook
is spawn)
3. rollback transaction to remove internal commits
4. .hg/bookmarks should be clean, because it isn't changed while
transaction running: see (2) above
But if shelve or unshelve is executed in the repository created with
"shared bookmarks" ("hg share -B"), this doesn't work as expected,
because:
- share extension makes 'bmstore.write()' write updated bookmarks
into .hg/bookmarks of shared source repository regardless of
transaction activity, and
- intentional transaction failure at the end of shelve/unshelve
doesn't restore already updated .hg/bookmarks of shared source
This patch makes share extension wrap 'bmstore._writerepo()' instead
of 'bmstore.write()', because the former is used to actually write
bookmark changes out.
c67339617276 (while 3.4 code-freeze) made all 'update' hooks run after
releasing wlock for visibility of in-memory dirstate changes. But this
breaks paired invocation of 'preupdate' and 'update' hooks.
For example, 'hg backout --merge' for TARGET revision, which isn't
parent of CURRENT, consists of steps below:
1. update from CURRENT to TARGET
2. commit BACKOUT revision, which backs TARGET out
3. update from BACKOUT to CURRENT
4. merge TARGET into CURRENT
Then, we expects hooks to run in the order below:
- 'preupdate' on CURRENT for (1)
- 'update' on TARGET for (1)
- 'preupdate' on BACKOUT for (3)
- 'update' on CURRENT for (3)
- 'preupdate' on TARGET for (4)
- 'update' on CURRENT/TARGET for (4)
But hooks actually run in the order below:
- 'preupdate' on CURRENT for (1)
- 'preupdate' on BACKOUT for (3)
- 'preupdate' on TARGET for (4)
- 'update' on TARGET for (1), but actually on CURRENT/TARGET
- 'update' on CURRENT for (3), but actually on CURRENT/TARGET
- 'update' on CURRENT for (4), but actually on CURRENT/TARGET
Root cause of the issue focused by c67339617276 is that external
'update' hook process can't view in-memory changes (especially, of
dirstate), because they aren't written out until the end of
transaction (or wlock).
Now, hooks can be invoked just after updating, because previous
patches made in-memory changes visible to external process.
This patch may break backward compatibility from the point of view of
"scheduling hook execution", but should be reasonable because 'update'
hooks had been executed in this order before 3.4.
This patch tests "hg backout" and "hg unshelve", because the former
activates the transaction before 'update' hook invocation, but the
former doesn't.
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.
