Merge could overwrite untracked files and cause data loss.
Instead we now handle the 'local side removed file and has untracked file
instead' case as the 'other side added file that local has untracked' case:
FILE: untracked file exists
abort: untracked files in working directory differ from files in requested revision
It could perhaps make sense to create .orig files when overwriting, either
instead of aborting or when overwriting anyway because of force ... but for now
we stay consistent with similar cases.
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.
changegroupsubset will take the parents of the roots to find the bases.
Other parts of Mercurial do not expect that, and a result of that is that some
bundles contain more changesets than necessary.
No real changes here - just renaming a parameter to document what it is.
A correct patch for this has existed in Python's BTS for 3 years
(http://bugs.python.org/issue9291), so waiting for it to be fixed
upstream is probably not a viable strategy. Instead, we add this
horrible hack to workaround the issue in existing copies of Python
2.4-2.7.
This note (which actually is a warning) frequently caused confusion.
"unsynced" is not a well established user-facing concept in Mercurial and the
message was not very specific or helpful.
Instead, show a messages like:
remote has heads on branch 'default' that are not known locally: 6c0482d977a3
and show it before aborting on "push creates new remote head". This will also
give more of a hint in the case where the branch has been closed remotely and
'hg heads' thus not would show any new heads after pulling.
A similar (but actually very different) message was addressed in cbd5a12a601a.
On windows, os.system runs the command in cmd.exe, which does not know command
substitution. To let this work, run the command explicitly in sh.
This fixes the failure of this test on windows.
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.
I mainly did the simple cases, like removing ".. note::", changing single
quotes to double quotes and adapting underlining.
Unhelpful msgstr in fuzzy entries are removed. (They were suggestions by the
program msgmerge.)
Before this changeset local clone of a repo with hidden changeset would include
then in the clone (why not) and turn them public (plain wrong). This happened
because the copy clone publish by dropping the phaseroot file entirely making
everything in the repo public (and therefore immune to obsolescence marker).
This changeset takes the simplest fix, we deny the copy clone in the case of hidden
changeset falling back to pull clone that will exclude them from the clone and
therefore not turning them public.
A smarter version of copy clone could be done, but I prefer to go for the
simplest solution first.
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.
Transform the backslashes to slashes on windows, because they are eaten up by
the shell. (Similar as done in test-check-pyflakes.t.)
This test will not produce a traceback on windows anymore. But the test still
fails because the detected mixed imports differ.
Installations with module names like
/usr/lib/python2.7/lib-dynload/bz2.x86_64-linux-gnu.so occurs in the wild.
Let's just ignore everything after first '.' when guessing the Python module
name.
Missing templates where not reported as a problem, only an empty bracket
were shown as indication of no found template directory:
$ hg debuginstall
*...some lines*
checking templates ()...
*...some lines*
no problems detected
Now the problem is reported and extended with some information. The style
of the messages is adapted to the other messages of debuginstall.
When no templates directories exist, it writes:
$ hg debuginstall
*...some lines*
checking templates ()...
no template directories found
(templates seem to have been installed incorrectly)
*...some lines*
1 problems detected, please check your install!
When the template map is not found, it writes:
$ hg debuginstall
*...some lines*
checking templates (/path/to/mercurial/templates)...
template 'default' not found
(templates seem to have been installed incorrectly)
*...some lines*
1 problems detected, please check your install!
When the template map is buggy the message is the same as before. The error
message is shown before the line "(templates seem ...)".
No test is added because testing this failure is complicated. It would
require to modify the templates directory of the mercurial installation,
or to monkey patch a function (os.listdir or any from mercurial.templater)
by a test extension.
This fixes mistake of documentation about matching against directories
in "pattern.txt" introduced by b99923dc748f.
".hgignore" treats specified "glob:" pattern as same as one specified
for "-X" option: it can match against directories, too.
For reference, extra regexp string appended to specified pattern for
each types are listed below: see also "match.match()" and
"match._regex()" for detail.
============= ========== ===============
type cmdline -I/-X
============= ========== ===============
glob/relglob '$' '(?:/|$)'
path/relpath '(?:/|$)' '(?:/|$)'
re/relre (none) (none)
============= ========== ===============
Appending '$' means that the specified pattern should match against
only files.
Before this patch, shell alias may be executed by abbreviated command
name unexpectedly, even if abbreviated command name matches also
against the command provided by extension.
For example, "rebate" shell alias is executed by "hg reba", even if
rebase extension (= "rebase" command) is enabled. In this case, "hg
reba" should be aborted because of command name ambiguity.
This patch makes "_checkshellalias()" invoke "cmdutil.findcmd()"
always with "strict=True" (default value).
If abbreviated command name matches against only one shell alias even
after loading extensions, such shell alias will be executed via
"_parse()".
This patch doesn't remove "_checkshellalias()" invocation itself,
because it may prevent shell alias from loading extensions uselessly.
