- Feb 19, 2016
-
-
Matt Harbison authored
-
- Feb 08, 2016
-
-
Katsunori FUJIWARA authored
Before this patch, "setup.py --pure" fails on Windows, because hgbuildscripts.run() tries to copy "hg.exe", which doesn't generated at "setup.py --pure". At that time, run_command('build_hgexe') invoked in hgbuildscripts.run() does nothing and returns successfully. Therefore, subsequent procedure assuming existence of "hg.exe" fails. This patch avoids procedure related to "hg.exe" (= all of hgbuildscripts.run() except for build_scripts.run() invocation) at "setup.py --pure".
-
- Feb 05, 2016
-
-
Yuya Nishihara authored
This should prevent processing backslashes as reST syntax elements. Before this patch, '\' was lost in HTML and man pages.
-
- Feb 06, 2016
-
-
Yuya Nishihara authored
Since we've dropped a str cast at write() by f04bd381e8c0, ui.prompt() should convert default to '' if it is None. Otherwise, write() would fail with "TypeError: object of type 'NoneType' has no len()". This patch includes the tests for both interactive and non-interactive cases because "ui.askusername" was never tested.
-
- Feb 10, 2016
-
-
Yuya Nishihara authored
f43988e5954c added 'ignoresub' argument to ui.configitems(), but zeroconf wrapper wasn't updated. It caused the following crash: Traceback (most recent call last): File "bin/hg", line 43, in <module> mercurial.dispatch.run() File "lib/python/mercurial/dispatch.py", line 54, in run sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255) File "lib/python/mercurial/dispatch.py", line 120, in dispatch ret = _runcatch(req) File "lib/python/mercurial/dispatch.py", line 191, in _runcatch return _dispatch(req) File "lib/python/mercurial/dispatch.py", line 924, in _dispatch cmdpats, cmdoptions) File "lib/python/mercurial/dispatch.py", line 681, in runcommand ret = _runcommand(ui, options, cmd, d) File "lib/python/mercurial/extensions.py", line 195, in closure return func(*(args + a), **kw) File "lib/python/hgext/zeroconf/__init__.py", line 180, in cleanupafterdispatch return orig(ui, options, cmd, cmdfunc) File "lib/python/mercurial/dispatch.py", line 1055, in _runcommand return checkargs() File "lib/python/mercurial/dispatch.py", line 1015, in checkargs return cmdfunc() File "lib/python/mercurial/dispatch.py", line 921, in <lambda> d = lambda: util.checksignature(func)(ui, *args, **cmdoptions) File "lib/python/mercurial/util.py", line 991, in check return func(*args, **kwargs) File "lib/python/mercurial/commands.py", line 5405, in paths pathitems = sorted(ui.paths.iteritems()) File "lib/python/mercurial/util.py", line 723, in __get__ result = self.func(obj) File "lib/python/mercurial/ui.py", line 619, in paths return paths(self) File "lib/python/mercurial/ui.py", line 1099, in __init__ for name, loc in ui.configitems('paths', ignoresub=True): File "lib/python/mercurial/extensions.py", line 195, in closure return func(*(args + a), **kw) TypeError: configitems() got an unexpected keyword argument 'ignoresub' We have no test coverage for zeroconf, so I've added a minimal test that could reproduce this problem.
-
- Feb 05, 2016
-
-
timeless authored
-
- Feb 02, 2016
-
-
Yuya Nishihara authored
Internal _matchfiles() function can take bunch of arguments, which would lead to a maximum recursion depth error. This patch avoids the excessive stack use by flattening 'list' nodes beforehand. Since getlist() no longer takes a nested 'list' nodes, _parsealiasdecl() also needs to flatten argument list, "aliasname($1, $2, ...)".
-
- Feb 05, 2016
-
-
André Sintzoff authored
-
- Feb 03, 2016
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Siddharth Agarwal authored
This backs out changeset 88fde8db5307. See the previous patches for why.
-
Siddharth Agarwal authored
This is a dependency for a future backout of 88fde8db5307. See the previous patches for why.
-
Siddharth Agarwal authored
This is a dependency for a future backout of 88fde8db5307. See the previous patches for why.
-
Siddharth Agarwal authored
This backs out changeset 804abe8999f3. See the previous patch for why we're doing this.
-
Siddharth Agarwal authored
This backs out changeset 39163708825c. There are some extra fields that absolutely should not be preserved, like the convert_revision field introduced by the convert and hgsubversion extensions. The problem with extensions blacklisting certain extra fields is that they might not be enabled at the time the amend is performed. In the long run we probably want separately marked transferable and non-transferable extra fields, but for now restore the old Mercurial 3.6 behavior.
-
Wagner Bruna authored
-
Yuya Nishihara authored
On Solaris, recvmsg() is provided by libsocket.so. We could try hard to look for the library which provides 'recvmsg' symbol, but it would make little sense now since recvfds() won't work anyway on Solaris. So this patch just disables _recvmsg() on such platforms. Thanks to FUJIWARA Katsunori for spotting this problem.
-
- Feb 02, 2016
-
-
Yuya Nishihara authored
It appears that Solaris doesn't provide CMSG_LEN(), msg_control, etc. As recvfds() is only necessary for chg, this patch just drops it if CMSG_LEN isn't defined, which is the same workaround as Python 3.x. https://hg.python.org/cpython/rev/c64216addd7f#l7.33
-
- Feb 03, 2016
-
-
Wagner Bruna authored
-
- Feb 01, 2016
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
- Jan 31, 2016
-
-
Martin von Zweigbergk authored
In df8973e1fb45 (verify: move file cross checking to its own function, 2016-01-05), "mflinkrevs = None" was moved into function, so the reference was cleared there, but the calling function now held on to the variable. The point of clearing it was presumably to free up memory, so let's move the clearing to the calling function where it makes a difference. Also change "mflinkrevs = None" to "del mflinkrevs", since the comment about scope now surely is obsolete.
-
- Feb 01, 2016
-
-
Martijn Pieters authored
Rather than look for the lowest revision, see if the rebase state is tracking the parents of this revision. Otherwise we can't handle multiple revisions in one rebase that includes a merge revision. Fixes issue5044.
-
Katsunori FUJIWARA authored
-
Wagner Bruna authored
-
Katsunori FUJIWARA authored
Before this patch, text blocks changed in this patch are shown as just continuous text blocks like below in HTML format. Global configuration like the username setting is typically put into: %USERPROFILE%\mercurial.ini $HOME/.hgrc This patch itemizes these text blocks to increase readability in HTML format. Global configuration like the username setting is typically put into: - %USERPROFILE%\mercurial.ini (on Windows) - $HOME/.hgrc (on Unix, Plan9) Like as other platform sensitive container-ed text blocks, this patch also adds explicit "on PLATFORM" information to each items for readability in HTML format, even though output of "hg help config" on command line seems a little redundant. For example, on Unix: Global configuration like the username setting is typically put into: - "$HOME/.hgrc" (on Unix, Plan9)
-
Katsunori FUJIWARA authored
This creates hg.1.html as expected.
-
Katsunori FUJIWARA authored
This patch fixes problems below: - ":hg:" role should be followed by not '"' but '`' - there is a help topic not "default-push" but "config.default-push"
-
Katsunori FUJIWARA authored
This creates hg.1.html as expected.
-
Katsunori FUJIWARA authored
This creates hg.1.html as expected.
-
Katsunori FUJIWARA authored
node.short() on 'ha' in verifyactions() causes broken hash ID, because it is initialized with node.hex()-ed node value.
-
- Jan 30, 2016
-
-
Yuya Nishihara authored
Because "backout --merge" have to make a commit before merging, it doesn't work with --no-commit. We could change "backout --merge" to make a merge commit automatically, and --no-commit to bypass a merge commit, but that change would be undesirable because: a) it's hard to fix bad merges in general b) two commits would be created with the same --message So, this patch simply disables "--merge --no-commit".
-
- Jan 27, 2016
-
-
Martin von Zweigbergk authored
In c0f11347b107 (changegroup: don't support versions 01 and 02 with treemanifests, 2016-01-19), I stopped supporting use of cg1 and cg2 with treemanifest repos. What I had not considered was that it's perfectly safe to pull *to* a treemanifest repo using any changegroup version. As reported in issue5066, I therefore broke pull from old repos into a treemanifest repo. It was not covered by the test case, because that pulled from a local repo while enabling treemanifests, which enabled treemanifests on the source repo as well. After switching to pulling via HTTP, it breaks. Fix by splitting up changegroup.supportedversions() into supportedincomingversions() and supportedoutgoingversions().
-
- Jan 28, 2016
-
-
Martin von Zweigbergk authored
-
- Jan 29, 2016
-
-
Siddharth Agarwal authored
In my patch series ending with rev 25e4b2f000c5 I switched most change/delete conflicts to be handled at the resolve layer. .hgsubstate was the one file that we weren't able to handle, so we kept the old code path around for it. The old code path added .hgsubstate to one of the other lists as the user specifies, including possibly the 'g' list. Now since we did this check after converting the actions from being keyed by file to being keyed by action type, there was nothing that actually removed .hgsubstate from the 'cd' or 'dc' lists. This meant that the file would eventually make its way into the 'mergeactions' list, now freshly augmented with 'cd' and 'dc' actions. We call subrepo.submerge for both 'g' actions and merge actions. This means that if the resolution to an .hgsubstate change/delete conflict was to add it to the 'g' list, subrepo.submerge would be called twice. It turns out that this doesn't cause any adverse effects on Linux due to caching, but apparently breaks on other operating systems including Windows. The fix here moves this to before we convert the actions over. This ensures that it .hgsubstate doesn't make its way into multiple lists. The real fix here is going to be: (1) move .hgsubstate conflict resolution into the resolve layer, and (2) use a real data structure for the actions rather than shuffling data around between lists and dictionaries: we need a hash (or prefix-based) index by file and a list index by action type. There's a very tiny behavior change here: collision detection on case-insensitive systems will happen after this is resolved, not before. I think this is the right change -- .hgsubstate could theoretically collide with other files -- but in any case it makes no practical difference. Thanks to Yuya Nishihara for investigating this.
-
- Jan 27, 2016
-
-
Nathan Goldbaum authored
-
Siddharth Agarwal authored
We've discovered an issue with this flag during certain kinds of rebases. When: (1) we're rebasing while currently on the destination commit, and (2) an untracked or ignored file F is currently in the working copy, and (3) the same file F is in a source commit, and (4) F has different contents in the source commit, then we'll try to merge the file rather than overwrite it. An earlier patch I sent honored the options for these situations as well. Unfortunately, rebases go through the same flow as the old, deprecated 'hg merge --force'. We'd rather not make any changes to 'hg merge --force' behavior, and there's no way from this point in the code to figure out whether we're in 'hg rebase' or 'hg merge --force'. Pierre-Yves David and I came up with the idea to split the 'force' flag up into 'force' for rebases, and 'forcemerge' for merge. Since this is a very disruptive change and we're in freeze mode, simply undocument the options for this release so that our hands aren't tied by BC concerns. We'll redocument them in the next release.
-
- Jan 28, 2016
-
-
Katsunori FUJIWARA authored
Before this patch, "hg pull --update" doesn't advance current active bookmark correctly, if pulling itself doesn't advance it, even though "hg pull" + "hg update" does so. Existing test for "pull --update works the same as pull && update" in test-bookmarks.t doesn't examine this case, because pulling itself advance current active bookmark before actual updating the working directory in that test case. To advance current active bookmark at "hg pull --update" correctly, this patch examines 'movemarkfrom' instead of 'not checkout'. Even if 'not checkout' at the invocation of postincoming(), 'checkout' is overwritten by "the revision to update to" value returned by destutil.destupdate() in such case. Therefore, 'not checkout' condition means "update destination is revision #0", and isn't suitable for examining whether active bookmark should be advanced. Even though examination around "movemarkfrom == repo['.'].node()" may seem a little redundant just for this issue, this makes it easier to compare (and unify in the future, maybe) with the same logic to update bookmark at "hg update" below. if not ret and movemarkfrom: if movemarkfrom == repo['.'].node(): pass # no-op update elif bookmarks.update(repo, [movemarkfrom], repo['.'].node()): ui.status(_("updating bookmark %s\n") % repo._activebookmark) else: # this can happen with a non-linear update ui.status(_("(leaving bookmark %s)\n") % repo._activebookmark) bookmarks.deactivate(repo)
-
- Jan 24, 2016
-
-
Matt Harbison authored
Previously, if the largefile was deleted at the time of a commit, the standin was silently not updated and its current state (possibly garbage) was recorded. The test makes it look like this is somewhat of an edge case, but the same thing happens when an `hg revert` followed by `rm` changes the standin. Aside from the second invocation of this in lfutil.updatestandinsbymatch() (which is what triggers this test case), the three other uses are guarded by dirstate checks for added or modified, or an existence check in the filesystem. So aborting in lfutil.updatestandins() should be safe, and will avoid silent skips in the future if this is used elsewhere.
-