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.
Before this patch, "contrib/check-code.py" can't detect these
problems, because the regexp pattern to detect "% inside _()" doesn't
suppose the case that format string consists of multiple string
components concatenated implicitly or explicitly,
This patch does below for that regexp pattern to detect "% inside _()"
problems in such case.
- put "+" into separator part ("[ \t\n]") for explicit concatenation
("...." + "...." style)
- enclose "component and separator" part by "(?:....)+" for
concatenation itself ("...." "...." or "...." + "....")
Before this patch, "contrib/check-code.py" can't detect these
problems, because the regexp pattern to detect "% inside _()" doesn't
suppose the case that the format string and "%" aren't placed in the
same line.
This patch replaces "\s" in that regexp pattern with "[ \t\n]" to
detect "% inside _()" problems in such case.
"[\s\n]" can't be used in this purpose, because "\s" is automatically
replaced with "[ \t]" by "_preparepats()" and "\s" in "[]" causes
nested "[]" unexpectedly.
Since changeset a8955c4d9ef5, "reposetup()" of each extensions is
invoked only on repositories enabling corresponded extensions.
This causes that largefiles specific interactions between the
repository enabling largefiles locally and remote (wire) peer fail,
because there is no way to know whether largefiles is enabled on the
remote repository behind the wire peer, and largefiles specific
"wireproto functions" are not given to any wire peers.
To avoid this problem, largefiles should be enabled in wider scope
than each repositories (e.g. user-wide "${HOME}/.hgrc").
This patch introduces "wirepeersetupfuncs" to setup wire peer by
extensions already enabled. Functions registered into
"wirepeersetupfuncs" are invoked for all wire peers.
This patch uses plain list instead of "util.hooks" for
"wirepeersetupfuncs", because the former allows to control order of
function invocation by order of extension enabling: it may be useful
for workaround of problems with combination of enabled extensions
Before this patch, manually edited commit message for "fold" command
in histedit-ing is never saved into ".hg/last-message.txt", because it
uses "localrepository.commitctx()" instead of
"localrepository.commit()": saving into ".hg/last-message.txt" is
executed only in the latter.
This patch saves manually edited commit message for "fold" command 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 for memctx should be centralized into the
framework like "localrepository.commit()" with "editor" argument or so
in the future.
Before this patch, manually edited commit message for "hg qfold -e"
isn't 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 "hg qfold -e" into
".hg/last-message.txt" just after user editing. This patch doesn't
save the message specified by -m/-l options as same as other commands.
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.
Before this patch, manually edited commit message for "hg qnew -e"
isn't 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 "hg qnew -e" into
".hg/last-message.txt" just after user editing. This patch doesn't
save the message specified by -m/-l options as same as other commands.
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.
Before this patch, "rebase --collapse --edit" without "--message" and
"--logfile" invokes editor twice unexpectedly:
1. explicit "ui.edit()" invocation in rebase extension itself
2. indirect invocation in "localrepository.commit()" with "editor =
commitforceeditor" assigned by "--edit" option
This patch uses indirect "commitforceeditor" invocation instead of
"ui.edit()" for "--collapse" without "--message" and "--logfile" to:
- suppress redundant the former invocation
- ensure editor invocation even when "--edit" is not specified
Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively
evaluate string literals as templates" problem (issue4103) by
introducing "_evalifliteral()".
But some parts in template expressions below are still processed by
the combination of "compiletemplate()" and "runtemplate()", and may
cause same problem unexpectedly.
- 'init' and 'hang' of 'fill(text, width, init, hang)'
- 'expr' of 'sub(pat, repl, expr)'
- 'label' of 'label(label, expr)'
This patch processes them by "_evalifliteral()" instead of the
combination of "compiletemplate()" and "runtemplate()" to avoid
recursive evaluation of string literals completely.
Now "hg purge -p" commands avoids printiing duplication of filenames.
Second patch is the test coverage of first patch which tells that '-p'
does not depend on whether ui.verbose is configured or not,that means it
is independent of '-v'.
Record was changing the current directory to `repo.root` in order to be able to
feed `command.commit` file name relative to this `repo.root`. This is a bit
overkill and prevent an incoming fix to rebase. This would also break
multi-threaded usage.
Instead we just feed `command.commit` with absolute path name. works as well as
before but without chdir.
The fix for issue2653 broke the ability to map the default branch of a source
repository to a non-default named branch in the destination repository. Leave
the default behaviour as is, but allow the branch name "None" to be used to map
to a non-default named branch in the destination repository.
This is a gratuitous code move aimed at reducing the localrepo bloatness.
The method had few callers, not enough to be kept in local repo.
The peer API remains unchanged.
The `pushoperation` object contains strictly more data the arguments currently
passed to `localrepo.checkpush` we pass the new object instead. This function is
used by MQ to abort push that includes MQ changesets.
Note: extension that may use this function will have to align.
This should correct an earlier couple of bad merges (5433856b2558 and
596960a4ad0d, now pruned) that accidentally brought in a change that had
been marked obsolete (244ac996a821).
Before this patch, "localrepository.commit()" omits ".hgsubstate" from
"modified" (changes[0]) and "removed" (changes[2]) file list before
checking subrepositories, but leaves one in "added" (changes[1]) as it
is.
Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or
"removed" list forcibly, according to subrepository statuses.
If "added" contains ".hgsubstate", the committed context will contain
two ".hgsubstate" in its "files": one from "added" (not omitted one),
and another from "modified" or "removed" (newly added one).
How many times ".hgsubstate" appears in "files" changes node hash,
even though revision content is same, because node hash calculation
uses the specified "files" directly (without duplication check or so).
This means that node hash of committed revision changes according to
existence of ".hgsubstate" in "added" at "localrepository.commit()".
".hgsubstate" is treated as "added", not only in accidental cases, but
also in the case of "qpush" for the patch adding ".hgsubstate".
This patch omits ".hgsubstate" also from "added" files before checking
subrepositories. This patch also omits ".hgsubstate" exclusion in
"qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this
patch makes them meaningless.
"hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t"
enhances checking unexpected multiple appearances of ".hgsubstate" in
"files" of created/refreshed MQ revisions.
When we specify a revision or a revset we just get the last element from the
list. For revsets this can lead to unintended effects where you specify a
revset like only() but instead histedit selects the highest revision in the
set as root. Therefore we should always use the lowest revision number as
root.
Some extensions set configuration settings that showed up in 'hg showconfig
--debug' with 'none' as source. That was confusing.
Instead, they will now tell which extension they come from.
This change tries to be consistent and specify a source everywhere - also where
it perhaps is less relevant.
Before this patch, even if specified file patterns and -I/-X options
cause listing ".hgsubstate" up in the target list, qnew/qrefresh put
".hgsubstate" into the target list individually and forcibly.
This changes how many times ".hgsubstate" appear in the target list
according to run-time conditions, and causes inconsistent node hash,
even though revision content is same, because node hash calculation
uses the specified target list directly (without duplication check or
so).
This patch always omits ".hgsubstate" from qnew/qrefresh target list
for consistent node hash.
This omitting doesn't miss including ".hgsubstate" changes, because:
- "localrepository.commit()" puts ".hgsubstate" into the target list
for "commitctx()" forcibly if needed
- "mq.putsubstate2changes()" puts ".hgsubstate" into the target list
for "patch.diff()" if it is not yet listed up
Before this patch, qnew puts updated subrepositories into target list
forcibly, if any of -I, -X or patterns are specified.
But this is meaningless and harmful, because:
- putting subrepositories into target list doesn't affect the result
of "localrepository.status()"
"dirstate.status()" invoked via "localrepository.status()" always
omits subrepositories from the result of it
- any -I/-X opts and empty "pats" causes unexpected failure
when any -I/-X opts are specified, "inclsubs" are always added to
"pats", even if "pats" is empty.
but this changes meaning of "pats" from "including all to be
included" to "including only listed subrepositories"
this may exclude ".hgsub" and cause unexpected exception raising
("can't commit subrepos without .hgsub" ).
- qnew at other than repository root (with -I, -X or any patterns)
causes unexpected failure
"scmutil.match()" treats pattern without syntax type as 'relpath'
type (= one rooted at cwd).
but qnew puts subrepository paths rooted at the repository root,
and it causes unexpected exception raising ("SUBREPO not under
root ROOT" in "pathutil.canonpath()"), if "hg qnew" is executed at
other than repository root with -I, -X or any patterns.
This patch omits meaningless and harmful putting subrepositories into
target list.
This omitting doesn't miss including updated subrepositories, because
subrepositories are specified to "scmutil.matchfiles()" directly, to
get "match" object for "localrepository.commit()".
This extension has always had correctness issues and has been
unmaintained for years. It is now removed in favor of the third-party
hgwatchman which is maintained and appears to be correct.
Users with inotify enabled in their config files will fall back to
standard status performance.
When the base is not found, we should not raise a traceback about a not defined
variable. This hides the real problem: the function rebasenode was (probably)
called wrong.
An AssertionError is raised to highlight that the caller of the function did
something wrong.
An alternative approach is to only assign None to the variable "base" and let
the merge mechanism raise an abort message. This was the behaviour for this
case before 544133bac670. But the only known case for this problem is when an
extension calls this function wrong. An AssertionError makes this clearer than
an abort message. When a different case is detected, the behaviour can be
improved then.
Subversion issues involving svn log such as 1e493b49245f can be tricky to
debug when it is run in an 'hg debugsvnlog' sub process. Debugging is simpler
when convert only uses one process.
With this change convert will invoke the svn log directly when setting
[convert]
svn.debugsvnlog = False
This is intentionally not documented.
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.
Shelve do normally take a list of files or patterns to shelve and the command
summary should thus show [FILE]...
Note: --delete is a bit special and interpret the parameters as a list of
shelve names. This change makes that even less obvious from the help. Too bad
- we can't please everyone.
publicancestors returned the parents of the public ancestors ... and
changegroupsubset used the parents of these as base for the bundle. That gave
bundles with one layer of changesets more than necessary.
Mercurial tags can be local (tag -l, stored in .hg/localtags) or global (normal
tags, tracked in .hgtags) ... or extensions can add other kind of tags.
Convert would take all tags (except "tip"), not just the ones from .hgtags, and
put them into .hgtags.
Instead, convert only the global tags that come from .hgtags.
This patch also replaces "editor = False" by "editor =
cmdutil.getcommiteditor()", because:
- it allows to hook commit message determination easily, even in the
case without "--edit"
- it avoids regression (or additional care) around saving
"last-message.txt", even if MQ's "newcommit()" changes its
implementation logic from "localrepository.commit" to
"localrepository.commitctx" with "memctx" in the future
to save commit message into "last-messge.txt" with "memctx",
"editor" should be valid function.
This patch also replaces "editor = False" by "editor =
cmdutil.getcommiteditor()", because:
- the latter allows to hook commit message determination easily,
even in the case without "--edit"
- the latter can avoid regression (or additional care) around saving
"last-message.txt", even if MQ's "newcommit()" changes its
implementation logic from "localrepository.commit" to
"localrepository.commitctx" with "memctx" in the future
to save commit message into "last-messge.txt" with "memctx",
"editor" should be valid function.
This patch also enhances "test-rebase-scenario-global.t", because "hg
rebase" hasn't been explicitly tested around editor invocation and
"--edit" option.
In the other hand, this patch doesn't enhance tests in "hg rebase
--collapse" case, because it is already tested in
"test-rebase-collapse.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.
Previously, there was no way to rewrite tags on the fly while converting. Now,
we add similar logic to branchmap to provide a way to map old tags to new tags.
Currently, this is not enabled since there is not yet a command-line option.
Previously, when converting from a mercurial repo there would be an extraneous
commit at the end of the convert process that would rewrite tags. Now, we check
if there are any new tags before doing this rewriting.
Previously, the hg sink for puttags would just use one head for getting the old
tags which would sometimes lead to tags disappearing. Now, we iterate over all
heads and merge the results.
Upcoming patches will add new map files so we change the calling sequence of
checkrevformat so that error messages will let the user know which file has the
wrong rev format.
This is a simple find-and-replace strategy for matching anything in the
old description of a converted commit and, if that matched sha1 exists
in the mapping, replacing it with the new sha1.
In particular, this is helpful for descriptions that contain tags with
messages such as, "Added tag 1.0 for commit abcde1234567" which will now
be automatically converted.
Tests have been updated accordingly.
It looks like somewhere down the line, patch.diffopts changed the
names of the options that it recognises, but record.recordfunc wasn't
updated to the new names. Instead of trying to write down names at
all, we now use whatever names are provided in commands.diffwsopts and
pass that along to patch.diffopts, along with a couple of custom
options
The record extension is writing its own version of commands.diffwsopts
which is identical to commands.diffwsopts. Based on the principle that
code duplication increases maintenance burden, this patch removes
record's ad-hoc diffopts in favour of commands.diffwsopts
The largefile hashes are mostly an implementation detail, but they are "leaked"
in several places anyway, and showing the hashes is better than not giving the
user any information about the options in the prompt.
The hashes are long, but it is largefile hashes and it would thus be confusing
to shorten them.
Before it tried to explain the exact situation when merging moved largefiles.
That do not happen for normal merges and is not more relevant for largefiles
than for normal files. It is unneeded complexity - remove it.
Before this patch, transplant extension shows the list of available
responses by specific string, even though the prompt string passed to
"ui.promptchoice()" has enough (maybe i18n-ed) information.
This patch uses "ui.extractchoices()" to show the list of available
responses.
Before this patch, transplant extension uses "ui.prompt()" for
interactive transplant, and has to check whether user response
returned by "ui.prompt()" is valid or not in own code.
In addition to it, transplant extension uses response characters
(e.g. "y", "n", and so on) directly in own code, and this disallows to
use another response characters by translation, even though the help
shown by '?' typing is translatable.
This patch uses "ui.promptchoice()" instead of "ui.prompt()" to
resolve problems above.
Before this patch, record extension gets the list of available
responses from online help document of "hg record" in the tricky way,
even though the value passed to "ui.promptchoice()" has enough (maybe
i18n-ed) information.
This patch uses "ui.extractchoices()" to get the list of available
responses.
Before it just said 'nothing to rebase'.
Now 'if "base" is an empty set:
abort: empty "base" revision set - can't compute rebase set
If the set of changesets to rebase can't be found from "base", it will fail as
before but with more explanation of what the problem was.
The name of the "base" option is not obvious - it is more like "samples
identifying the branch to rebase". The error messages for problems with the
specified "base" value will use that term and might thus also not be obvious,
but at least they are consistent with the option name. The name "base" will not
be used if the base only was specified implicitly as the working directory
parent.
Before, it just said 'nothing to rebase' in this case. Now, it aborts
mentioning the reason: 'empty "source" revision set'.
Specifying revisions that cannot be rebased is a 'soft' error, but specifying
an empty set deserves an abort that explains exactly what the problem is.
Before, it just said 'nothing to rebase' in this case. Now, it aborts
mentioning the reason: 'empty "rev" revision set'.
Specifying revisions that cannot be rebased is a 'soft' error, but specifying
an empty set deserves an abort that explains exactly what the problem is.
Since the localrepositoyry.push() method in mercurial/localrepo.py is defined
this way:
def push(self, remote, force=False, revs=None, newbranch=False):
it is better for largefiles to call push() on the super class with proper
kwargs to respect the API.
This will avoid breaking other extensions overriding the push method this way:
def push(self, remote, force=False, **kwargs):
The -u flag didn't work when ui.username was not set and resulted in an
abort message. This was fixed by checking for the 'user' key in the opts
dictionary. If the key is present, the step causing the exception is not
executed.
Previously, unshelve would temporarily commit unknown files (via addremove) in
an attempt to allow unshelving into unknown files. This produced unexpected
results, like the file time stamp changing and a .i file being created.
This change makes it no longer use addremove. It ignores unknown files
completely. If an unshelve would overwrite an unknown file, the unknown file is
moved to *.orig
The shelve continue/abort format is changed, but it just removes stuff from the
end of the file, so it can still read the old format.
a8386b4c47b1 introduced splitstandin on all action filenames. It would however
crash on 'd' actions where the filename is None.
Fix that and add test coverage for that case.
The [x for y in l for x in y] syntax is nigh-incomprehensible, and this
is a particularly easy case to expand into a loop since there's no 'if'
condition in the list comprehension.
Previously, we'd acquire and release the wlock several times. This meant that
other hg processes could come in and change state. Instead of that, retain the
wlock for the entire duration of the strip.
Add a first check of the devices before collecting candidate files. This is
much quicker when big repos are on different devices.
Keep the existing check in prune. It checks for same device of the files. This
could probably be different in a special repo store (with symlinks).
Currently, histedit acquires and releases lock and wlock several times during
its run. This isn't great because it allows other hg processes to come in and
change state. With this fix, lock and wlock are acquired and released exactly
once.
The change to test-histedit-drop.t is a minor implementation one -- the cache
is still correctly invalidated, but it just happens a little later and only
gets printed out because of the unrelated --debug flag.
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.
An update would try to fetch any missing largefiles after having updated normal
files and standins. That could fail or be interrupted and would leave the
working directory in a state where the largefiles not only were missing but
also were scheduled for remove ... and where the old largefile was left in
place.
Instead we now remove old largefiles before starting to download and update
missing largefiles.
get_log started calling back with orig_paths=None on Fedora 20 with
subversion-1.8.3. That broke test-convert-svn-source.t .
There used to be some handling of that situation until d17c619e40d5 apparently
broke it. This patch restores what seems to be the most obvious handling of the
situation.
When running the unshare command, if there's other code that tries to use
the repo after the command is finished, it'll end up with a ui object for
repo.unfiltered(). This change fixes an erroneous call to repo.__init__()
that could be on the repoview proxy class--now it's always done on the
unfiltered repo.
Before this patch, transplant with "--merge" option fails with
traceback unexpectedly, if it causes pull from the source repository
on the local host.
"discovery.findcommonincoming()" invokes "capable()" method on the
object given from "localrepository.pull()", but it is
"localrepository" object in this case and doesn't have such method.
This patch uses peer object of source repository as "remote" argument
for "localrepository.pull()" invocation like other invocations of it
in transplant.py.
Rebasing with --collapse would leave the working copy on the parent of the
collapsed commit, instead of on the collapsed commit. This fixes that. Also
fixes a few tests that already covered this area but had bad data.
This also fixes issue3716 where bookmarks are not kept across rebases with
--collapse. I updated the test to cover that case as well.
When aborting a rebase where tip-1 is public, rebase would fail to undo the merge
state. This caused unexpected dirstate parents and also caused unshelve to
become unabortable (since it uses rebase under the hood).
The problem was that rebase uses -2 as a marker rev, and when it checked for
immutableness during the abort, -2 got resolved to the second to last entry in
the phase cache.
Adds a test for the fix. Add exception to phase code to prevent this in the
future.
Fix test-check-pyflakes.t error after 98058c06ff6b.
This patch replaces "readshelvedfiles()" invocation by
"shelvedfile().exists()" check and aborting, because it is required
only to ensure that shelved changes corresponded to specified name
exist after invocation.
This patch also remove definition of "readshelvedfiles()" itself,
because it is invoked only from the line removed by this patch.
Prior this changeset, rebasing a merge whose first parent was not in
the rebase lead to wrong and highly conflicting merge. See the in-line
comment for details.
Test have been updated with the data provided by the reported.
Prompts like
foo has been turned into a largefile
use (l)argefile or keep as (n)ormal file?
was not as clear as the usual prompts that use 'remote' or 'local' to explain
what happened on which side ... especially not when used to the normal prompts.
"as" could also indicate that it would be possible to take the content of the
largefile and somehow put it into the normal file. It could make it more clear
that it was a choice between one side or the other.
For consistency we will now phrase it like:
remote turned local normal file f into a largefile
use (l)argefile or keep (n)ormal file?
This patch removes code paths in "shelvedfile.opener()", because:
- explicit "vfs.mkdir()" invocation is useless
"vfs.__call__()" for modes other than "read" creates parent
directory of target file automatically by "util.ensuredirs()".
- mode checking in "except IOError" code path is useless
ENOENT occurs only for "read" mode, because target file is
created forcibly for other modes.
- there is no explicit "return" statement in the code path for
"except IOError" if "mode[0] in 'wa'"
this is incorrect, because None may be returnd unexpectedly,
even though it seems the EEXIST case in the directory creation
race for ".hg/shelved" and is very rare.
this directory creation race is also treated in
"util.ensuredirs()".
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
On Windows, only double quotation mark can quote command line
arguments.
So, this patch uses double quotation mark to quote command line
arguments in all examples of online help document.
We used to get like:
$ hg up -r 2
foo has been turned into a normal file
keep as (l)argefile or use (n)ormal file? l
getting changed largefiles
0 largefiles updated, 0 removed
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ cat foo
cat: foo: No such file or directory
[1]
- which both asked the wrong question and did the wrong thing.
Instead, skip this conflict resolution when the local conflicting file has been
scheduled for removal and there thus is no conflict.
If paging is configured for a command all it's internal defined aliases
will be paged as well. This will make attend=log cause 'hg history'
to run the pager. However custom aliases will not be paged by default.
Before this patch, each feature setup functions for localrepository
class should examine whether corresponding extension is enabled or not
by themselves.
This patch invokes only feature setup functions defined in module of
enabled extensions, and it makes implementation of feature setup
functions easier and simpler.
Prior to this changeset, rebase always left the working directory as a parent of
the last rebased changeset. The is dubious when, before the rebase, the working
directory was not a parent of the tip most rebased changeset.
With this changeset, we move the working directory back to its original parent.
If the original parent was rebased, we use it's successors.
This is a step toward solving issue3813 (rebase loses active bookmark if it's
not on a head)
Before the hack would replace 'heads' with 'lheads' no matter where it occured
in a batch command string.
Instead we will use a regexp to more carefully only match the 'heads' commands.
Pickle was used to the `shelvedstate` file. However the content of the file is
very simple and we can handle serialisation ourself. Not using pickle is a net
win.
Note incrementing the format version as no releases have been done so far.
The reverse mapping was introduced in 51f9f23e6ccc to make roundtrip
conversions possible ... but it did not work when using filemap.
Roundtrips with filemaps will of course only work flawlessly if inverse
mappings are used.
Especially, if a lossy convert mapping is used in one direction, then only
linear lines of development can be converted in the other direction. With this
constraint convert will do the right thing by assuming that excluded files
haven't been changed.)
A test case with general coverage of hg-hg roundtrips with filemap is added.
(There a cases where adding records of converted revisions to the shamap in the
source repository doesn't work - especially when converting the same repo to
several other repos and back. It would arguably be better if convert only
updated the shamaps in the target repo but read shamaps from both the source
and and target repo ... but that is a different story. Making the stuff we have
work consistently is step forward no matter what.)
The existing knobs for controlling which revisions to convert were often
insufficient. Revsets is a shiny hammer that provides a better solution.
Revsets has been introduced in --rev handling in a lot of other places while
being more or less backwards compatible. Doing the same here would be a much
more elegant ... but that would unfortunately not work in this case. "--rev 7"
used to mean revision 0 to 7 - it would be an unacceptable change if it
suddenly just meant revision 7.
Instead we introduce a new configuration setting. It will only work for
Mercurial repositories so adding a new commandline option for it would not be a
nice solution.
There is no way to use the fancy deprecation markup for configuration settings
so we just remove the documentation of hg.startrev.
destc is not a string and can thus not be os.path.join'ed. Convert would crash
if we ended up there ... but we wouldn't because both the sinks (hg and
subversion) sinks implement .revmapfile and "never" throws exceptions.
If you shelved on top of commit A, then rebased A to @ and unshelved, any file
changed in A would appear as modified in hg status despite the contents not having
changed.
The fix is to use dirstate.setparents() instead of doing it manually. This will
be a little slower since it has to iterate through everything in the dirstate
instead of only what's in the mergestate, but this will be more correct since
the mergestate did not include files which were merged but had no conflict.
The tests also had several bad dirstate's hardcoded in them. This change updates
the tests appropriately and adds a new test to cover this specific rebase case.
cmdutil.commit() will advance the bookmarks. Therefore we have to restore
them afterwards. We have to use update() to ensure we preserve the bmstore
object.
An upcoming patch will move pidfile writing from the parent to the child. This
means that if the pid file isn't specified on the command-line but is specified
as a config option, it needs to be added to the parent's opts dict.
This makes it possible to pass keepbranches and extrafn to rebase at
the same time, although nobody uses that functionality presently. This
is a precursor to keeping graft metadata.
We allow shelving of of changes on top of a MQ repository. MQ will
not allow repository changes on top of applied patches. We introduce
checkapplied in MQ to bypass this check.
Use a more condensed and mercurial-like output format for shelve listing.
We don't prefix the message with 'shelved from...' anymore as our default
name contains the branch name or the user used his own name. To avoid
just printing the last commit message, we drop writing the description
to stdout.
old output:
default [1s ago] shelved from default (01ba9745): create conflict
new output:
default (1s ago) create conflict
This extension saves shelved changes using a temporary draft commit,
and bundles the temporary commit and its draft ancestors, then
strips them.
This strategy makes it possible to use Mercurial's bundle and merge
machinery to resolve conflicts if necessary when unshelving, even
when the destination commit or its ancestors have been amended,
squashed, or evolved. (Once a change has been unshelved, its
associated unbundled commits are either rolled back or stripped.)
Storing the shelved change as a bundle also avoids the difficulty
that hidden commits would cause, of making it impossible to amend
the parent if it is a draft commits (a common scenario).
Although this extension shares its name and some functionality with
the third party hgshelve extension, it has little else in common.
Notably, the hgshelve extension shelves changes as unified diffs,
which makes conflict resolution a matter of finding .rej files and
conflict markers, and cleaning up the mess by hand.
We do not yet allow hunk-level choosing of changes to record.
Compared to the hgshelve extension, this is a small regression in
usability, but we hope to integrate that at a later point, once the
record machinery becomes more reusable and robust.
Before this patch, "hg summary" may fail, when there is inconsistent
rebase state: for example, the root of rebase destination revisions
recorded in rebase state file is already stripped manually.
Mercurial earlier than 2.7 allows users to do anything other than
starting new rebase, even though current rebase is not finished or
aborted yet. So, such inconsistent rebase states may be left and
forgotten in repositories.
This patch catches RepoLookupError at restoring rebase state for
summary hook, and treat such state as "broken".
Before this patch, "rebase --abort"/"--continue" may fail, when rebase
state is inconsistent: for example, the root of rebase destination
revisions recorded in rebase state file is already stripped manually.
Mercurial earlier than 2.7 allows users to do anything other than
starting new rebase, even though current rebase is not finished or
aborted yet. So, such inconsistent rebase states may be left and
forgotten in repositories.
This patch catches RepoLookupError at restoring rebase state for
abort/continue, and treat such state as "broken".
Mercurial earlier than 2.7 allows users to do anything other than
starting new histedit, even though current histedit is not finished or
aborted yet. So, unfinished (and maybe inconsistent now) histedit
states may be left and forgotten in repositories.
Before this patch, histedit extension shows the message below, when it
detects such inconsistent state:
abort: REV is not an ancestor of working directory
(update to REV or descendant and run "hg histedit --continue" again)
But this message is incorrect, unless old Mercurial is re-installed,
because Mercurial 2.7 or later disallows users to update the working
directory to another revision.
This patch changes the hint message to suggest "hg histedit --abort".
