Sun, 12 Nov 2017 00:24:38 -0500 test-largefiles: demonstrate problems with renaming and reverting a directory stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 12 Nov 2017 00:24:38 -0500] rev 34993
test-largefiles: demonstrate problems with renaming and reverting a directory These things were uncovered looking at issue5738. First, if the destination directory exists under .hglf, the source is moved under the destination instead of renaming the last component for `hg mv srcdir dstdir`. This is extra confusing, because it occurs even if the user visible destination (i.e. the path _not_ under .hglf) does not exist. Additionally, when a largefile is forgotten via revert, any modifications end up getting clobbered. For normal files, the forgotten file is left unchanged, as shown by test-import.t. The forget command on a largefile will correctly leave the file unmodified.
Sat, 11 Nov 2017 12:37:05 -0500 tests: add globs for Windows stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 11 Nov 2017 12:37:05 -0500] rev 34992
tests: add globs for Windows
Sat, 25 Nov 2017 15:29:34 +0900 cat: record the current behavior of wildcard matches in subrepos stable
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Nov 2017 15:29:34 +0900] rev 34991
cat: record the current behavior of wildcard matches in subrepos Mercurial subrepos support any match patterns.
Wed, 29 Nov 2017 17:49:08 -0500 merge with i18n stable
Augie Fackler <augie@google.com> [Wed, 29 Nov 2017 17:49:08 -0500] rev 34990
merge with i18n
Tue, 21 Nov 2017 13:50:25 -0200 i18n-pt_BR: synchronized with cabc840ffdee stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 21 Nov 2017 13:50:25 -0200] rev 34989
i18n-pt_BR: synchronized with cabc840ffdee
Tue, 28 Nov 2017 23:20:08 -0500 convert: avoid wrong lfconvert defaults by moving configitems to core stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Nov 2017 23:20:08 -0500] rev 34988
convert: avoid wrong lfconvert defaults by moving configitems to core The `hg lfconvert --to-normal` command uses the convert extension internally to work its magic, but that produced devel-warn messages if the convert extension wasn't loaded by the user. The test in fcd2f9b06629 (modified here) wasn't showing the warnings because the convert extension was loaded via $HGRCPATH. Most of the config options default to None/False, but 'hg.usebranchnames' and 'hg.tagsbranch' are supposed to default to True and 'default' respectively. The first iteration of this was to ui.setconfig() inside lfconvert, to force the convert extension to load. But there really is no precedent for doing this, and check-config complained that 'extensions.convert' isn't documented. Yuya suggested this alternative. This partially backs out 0d5a1175d0f9.
Fri, 24 Nov 2017 21:51:41 -0500 tr-summary: keep a weakref to the unfiltered repository stable
Boris Feld <boris.feld@octobus.net> [Fri, 24 Nov 2017 21:51:41 -0500] rev 34987
tr-summary: keep a weakref to the unfiltered repository Repoview can have a different life cycle, causing issue in some corner cases. The particular instance that revealed this comes from localpeer. The localpeer hold a reference to the unfiltered repository, but calling 'local()' will create an on-demand 'visible' repoview. That repoview can be garbaged collected any time. Here is a simplified step by step reproduction:: 1) tr = peer.local().transaction('foo') 2) tr.close() After (1), the repoview object is garbage collected, so weakref used in (2) point to nothing. Thanks to Sean Farley for helping raising and debugging this issue.
Sat, 11 Nov 2017 12:40:13 +0900 dispatch: verify result of early command parsing stable
Yuya Nishihara <yuya@tcha.org> [Sat, 11 Nov 2017 12:40:13 +0900] rev 34986
dispatch: verify result of early command parsing Before, early options were stripped from args, and because of this, some kind of parsing errors weren't reported. For example, $ hg ci -m -Ra file would execute "hg ci -m file" in repository "a". This patch fixes the issue by parsing early options again by real getopt-based parser, and verifying the results. If the early parsing appears wrong, hg just aborts. The current error message seems not nice, and should be improved, maybe in V2 or follow-up. Note that this isn't a security feature because we can still do anything by using shell aliases.
Sat, 11 Nov 2017 17:55:15 +0900 dispatch: convert non-list option parsed by _earlygetopt() to string stable
Yuya Nishihara <yuya@tcha.org> [Sat, 11 Nov 2017 17:55:15 +0900] rev 34985
dispatch: convert non-list option parsed by _earlygetopt() to string So we can easily compare it with the corresponding getopt() result. There's a minor behavior change. Before, "hg --cwd ''" failed with ENOENT. But with this patch, an empty cwd is silently ignored. "hg -R ''" has always worked as such, so -R has no BC.
Sat, 11 Nov 2017 16:46:41 +0900 dispatch: add option to not strip command args parsed by _earlygetopt() stable
Yuya Nishihara <yuya@tcha.org> [Sat, 11 Nov 2017 16:46:41 +0900] rev 34984
dispatch: add option to not strip command args parsed by _earlygetopt() This allows us to parse the original args later by full-blown getopt() in order to verify the result of the faulty early parsing. Still we need the 'strip=True' behavior for shell aliases. Note that this series is RFC because it seems to change too much to be included in stable release.
Tue, 14 Nov 2017 00:25:59 +0900 dispatch: fix early parsing of short option with value like -R=foo stable
Yuya Nishihara <yuya@tcha.org> [Tue, 14 Nov 2017 00:25:59 +0900] rev 34983
dispatch: fix early parsing of short option with value like -R=foo Before, -R=foo was parsed as '-R' 'foo', which disagrees with the standard getopt behavior.
Sat, 11 Nov 2017 14:02:41 +0900 dispatch: abort if early boolean options can't be parsed stable
Yuya Nishihara <yuya@tcha.org> [Sat, 11 Nov 2017 14:02:41 +0900] rev 34982
dispatch: abort if early boolean options can't be parsed Perhaps we'll need to restrict the parsing rules of --debugger and --profile, where this patch will help us know why the --debugger option doesn't work. I have another series to extend this feature to --config/--cwd/-R, but even with that, shell aliases can be used to get around the restriction.
Fri, 10 Nov 2017 22:27:26 +0900 dispatch: stop parsing of early boolean option at "--" stable
Yuya Nishihara <yuya@tcha.org> [Fri, 10 Nov 2017 22:27:26 +0900] rev 34981
dispatch: stop parsing of early boolean option at "--"
Fri, 10 Nov 2017 22:22:39 +0900 dispatch: extract stub function to peek boolean command option stable
Yuya Nishihara <yuya@tcha.org> [Fri, 10 Nov 2017 22:22:39 +0900] rev 34980
dispatch: extract stub function to peek boolean command option We should at least stop parsing at "--". The 'name' argument is passed for future extension.
Sat, 11 Nov 2017 12:09:19 +0900 dispatch: do not drop unpaired argument at _earlygetopt() stable
Yuya Nishihara <yuya@tcha.org> [Sat, 11 Nov 2017 12:09:19 +0900] rev 34979
dispatch: do not drop unpaired argument at _earlygetopt() Before, "hg log -R" just worked.
Sat, 04 Nov 2017 20:07:40 +0900 amend: update .hgsubstate before committing a memctx (issue5677) stable
Yuya Nishihara <yuya@tcha.org> [Sat, 04 Nov 2017 20:07:40 +0900] rev 34978
amend: update .hgsubstate before committing a memctx (issue5677) This is a minimal copy of localrepo.commit(). As the current amend() function heavily depends on the wctx API, it wasn't easy to port it to use a separate status tuple. So for now, wctx._status is updated in-place.
Sat, 04 Nov 2017 19:21:39 +0900 subrepo: extract preprocess of repo.commit() to free function stable
Yuya Nishihara <yuya@tcha.org> [Sat, 04 Nov 2017 19:21:39 +0900] rev 34977
subrepo: extract preprocess of repo.commit() to free function No code change other than extracting a function. Maybe we should stop mutating the status argument, but that's out of the scope of stable changes.
Sat, 04 Nov 2017 18:54:57 +0900 tests: demonstrate that .hgsubstate isn't updated on amend stable
Yuya Nishihara <yuya@tcha.org> [Sat, 04 Nov 2017 18:54:57 +0900] rev 34976
tests: demonstrate that .hgsubstate isn't updated on amend Loosely based on test-amend.t and test-subrepo.t
Sat, 04 Nov 2017 23:48:19 +0900 amend: do not drop missing files (issue5732) stable
Yuya Nishihara <yuya@tcha.org> [Sat, 04 Nov 2017 23:48:19 +0900] rev 34975
amend: do not drop missing files (issue5732) samefile() can be wrong since wctx.manifest() does not include missing files, whereas missing files should be preserved on commit.
Sat, 04 Nov 2017 23:45:59 +0900 amend: do not take untracked files as modified or clean (issue5732) stable
Yuya Nishihara <yuya@tcha.org> [Sat, 04 Nov 2017 23:45:59 +0900] rev 34974
amend: do not take untracked files as modified or clean (issue5732) fctx.exists() shouldn't be used here as it checks if a file physically exists, which may disagree with the dirstate.
Sat, 04 Nov 2017 23:40:26 +0900 tests: add more complete test for status changes on amend stable
Yuya Nishihara <yuya@tcha.org> [Sat, 04 Nov 2017 23:40:26 +0900] rev 34973
tests: add more complete test for status changes on amend This demonstrates that missing/untracked files are handled incorrectly. The correct outputs are suppressed by (false !), and wrong outputs are added with (true !) instead. The setup code is copied from test-status-rev.t.
Fri, 03 Nov 2017 09:27:36 -0700 scmutil: don't try to delete origbackup symlinks to directories (issue5731) stable
Mark Thomas <mbthomas@fb.com> [Fri, 03 Nov 2017 09:27:36 -0700] rev 34972
scmutil: don't try to delete origbackup symlinks to directories (issue5731) When origbackuppath is set, when looking to see if a file we are backing up conflicts with a directory in the origbackuppath, we incorrectly match on symlinks to directories. This means we try to call vfs.rmtree on the symlink, which fails. Differential Revision: https://phab.mercurial-scm.org/D1311
Fri, 03 Nov 2017 09:27:35 -0700 tests: add a test demonstrating issue5731 stable
Mark Thomas <mbthomas@fb.com> [Fri, 03 Nov 2017 09:27:35 -0700] rev 34971
tests: add a test demonstrating issue5731 If origbackups are in use, a symlink to a valid directory is backed up, and an update is made that attempts to backup a file or link over that symlink, we abort with a bad error message instead of successfully updating. Differential Revision: https://phab.mercurial-scm.org/D1310
Tue, 07 Nov 2017 13:15:35 -0500 Added signature for changeset cabc840ffdee stable
Augie Fackler <raf@durin42.com> [Tue, 07 Nov 2017 13:15:35 -0500] rev 34970
Added signature for changeset cabc840ffdee
Tue, 07 Nov 2017 13:15:34 -0500 Added tag 4.4.1 for changeset cabc840ffdee stable
Augie Fackler <raf@durin42.com> [Tue, 07 Nov 2017 13:15:34 -0500] rev 34969
Added tag 4.4.1 for changeset cabc840ffdee
Tue, 07 Nov 2017 11:22:24 -0500 stable: merge with security patches stable 4.4.1
Augie Fackler <augie@google.com> [Tue, 07 Nov 2017 11:22:24 -0500] rev 34968
stable: merge with security patches
Mon, 06 Nov 2017 22:32:41 -0800 subrepo: use per-type config options to enable subrepos stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 06 Nov 2017 22:32:41 -0800] rev 34967
subrepo: use per-type config options to enable subrepos We change subrepos.allowed from a list of allowed subrepo types to a combination of a master switch and per-type boolean flag. If the master switch is set, subrepos can be disabled wholesale. If subrepos are globally enabled, then per-type options are consulted. Mercurial repos are enabled by default. Everything else is disabled by default.
Mon, 06 Nov 2017 14:56:17 -0500 config: add some more documentation around why svn and git subrepos are off stable
Augie Fackler <augie@google.com> [Mon, 06 Nov 2017 14:56:17 -0500] rev 34966
config: add some more documentation around why svn and git subrepos are off
Sun, 05 Nov 2017 21:51:42 +0900 subrepo: disable git and svn subrepos by default (BC) (SEC) stable
Yuya Nishihara <yuya@tcha.org> [Sun, 05 Nov 2017 21:51:42 +0900] rev 34965
subrepo: disable git and svn subrepos by default (BC) (SEC) We have a security issue with git subrepos. I'm not sure if svn subrepo is vulnerable, but it seems not 100% safe to allow writing arbitrary data into a metadata directory. So for now, only hg subrepo is enabled by default. Maybe we should improve the help to describe why git/svn subrepos are disabled.
Sun, 05 Nov 2017 21:48:58 +0900 subrepo: extend config option to disable subrepos by type (SEC) stable
Yuya Nishihara <yuya@tcha.org> [Sun, 05 Nov 2017 21:48:58 +0900] rev 34964
subrepo: extend config option to disable subrepos by type (SEC) This allows us to minimize the behavior change introduced by the next patch. I have no idea which config style is preferred in UX POV, but I decided to get things done. a) list: 'allowed = hg, git, svn' b) sub option: 'allowed.hg = True' or 'allowed:hg = True' c) per-type action: 'hg = allow', 'git = abort'
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip