Sat, 16 Dec 2017 12:34:40 -0500 tests: fix the check-code rule for testing non-existent files
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Dec 2017 12:34:40 -0500] rev 35447
tests: fix the check-code rule for testing non-existent files I missed this in feecfefeba25.
Sat, 16 Dec 2017 11:32:10 -0500 tests: convert the 'file://\$TESTTMP' rule to an automatic substitution
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Dec 2017 11:32:10 -0500] rev 35446
tests: convert the 'file://\$TESTTMP' rule to an automatic substitution The rule only triggered on non Windows platforms, even though Windows also required an adjustment. Automatic seems better. The aggressive globbing in test-subrepo-svn.t was found and rewritten by the substitution.
Sat, 21 Oct 2017 17:27:14 +0900 help: deprecate ui.slash in favor of slashpath template filter (issue5572)
Yuya Nishihara <yuya@tcha.org> [Sat, 21 Oct 2017 17:27:14 +0900] rev 35445
help: deprecate ui.slash in favor of slashpath template filter (issue5572) > For some reason, I thought someone (Mads?) said we had basically given > up on ui.slash, and some commands didn't support it. (from https://bz.mercurial-scm.org/show_bug.cgi?id=5572#c1) So the ui.slash option doesn't always work and is somewhat confusing. Let's make it clearer we won't improve the situation.
Sat, 21 Oct 2017 17:19:02 +0900 templatefilters: add slashpath() to convert path separator to slash
Yuya Nishihara <yuya@tcha.org> [Sat, 21 Oct 2017 17:19:02 +0900] rev 35444
templatefilters: add slashpath() to convert path separator to slash Prepares for deprecating the ui.slash option, which isn't always respected.
Thu, 14 Dec 2017 22:26:46 +0900 check-code: remove unused variable 'winglobmsg'
Yuya Nishihara <yuya@tcha.org> [Thu, 14 Dec 2017 22:26:46 +0900] rev 35443
check-code: remove unused variable 'winglobmsg' Follows up 5feb782c7a95.
Thu, 14 Dec 2017 22:37:10 +0900 phases: initialize number of loaded revisions to 0
Yuya Nishihara <yuya@tcha.org> [Thu, 14 Dec 2017 22:37:10 +0900] rev 35442
phases: initialize number of loaded revisions to 0 As it isn't a revision number, an empty value should be 0, not -1.
Thu, 14 Dec 2017 22:35:37 +0900 phases: rename _phasemaxrev to _loadedrevslen to clarify it isn't max value
Yuya Nishihara <yuya@tcha.org> [Thu, 14 Dec 2017 22:35:37 +0900] rev 35441
phases: rename _phasemaxrev to _loadedrevslen to clarify it isn't max value "maxrev" sounds like max(0:tip), but it is actually len(0:tip).
Tue, 12 Dec 2017 15:16:02 -0500 lfs: add an experimental config to override User-Agent for the blob transfer
Matt Harbison <matt_harbison@yahoo.com> [Tue, 12 Dec 2017 15:16:02 -0500] rev 35440
lfs: add an experimental config to override User-Agent for the blob transfer This will allow developers to test against various server implementations. I didn't put it under [devel] because it's possible that some user needs to use it in the field.
Thu, 14 Dec 2017 13:04:08 -0500 lfs: add git to the User-Agent header for blob transfers
Matt Harbison <matt_harbison@yahoo.com> [Thu, 14 Dec 2017 13:04:08 -0500] rev 35439
lfs: add git to the User-Agent header for blob transfers As we were trying to transition off of the non production lfs-test-server for further experimenting, one of the problems we ran into was interoperability. A coworker setup gitbucket[1] to act as the blob server, tested with git, and passed it off to me. But push failed with a message saying "abort: LFS server returns invalid JSON:", and then proceeded to dump a huge HTML page to the screen. It turns out that it is assuming that git is the only thing that wants to do a blob transfer, and everything else is a web browser wanting HTML. It's only a single data point, but I suspect other things may be doing this too. RFC7231 gives an example [2] of listing multiple products in decreasing order of significance. Since the standard provides for this, and since it works with the one problematic server I found, I'm just enabling this by default for a better UX. There's nothing significant about the version of git chosen, other than it is the current version. [1] https://github.com/gitbucket/gitbucket/ [2] https://tools.ietf.org/html/rfc7231#page-46
Thu, 14 Dec 2017 15:03:55 -0800 outgoing: respect ":pushurl" paths (issue5365)
Hollis Blanchard <hollis_blanchard@mentor.com> [Thu, 14 Dec 2017 15:03:55 -0800] rev 35438
outgoing: respect ":pushurl" paths (issue5365) Make 'hg outgoing' respect "paths.default:pushurl" in addition to "paths.default-push". 'hg outgoing' has always meant "what will happen if I run 'hg push'?" and it's still documented that way: Show changesets not found in the specified destination repository or the default push location. These are the changesets that would be pushed if a push was requested. If the user uses the now-deprecated "paths.default-push" path, it continues to work that way. However, as described at https://bz.mercurial-scm.org/show_bug.cgi?id=5365, it doesn't behave the same with "paths.default:pushurl". Why does it matter? Similar to the bugzilla reporter, I have a read-only mirror of a non-Mercurial repository: upstream -> imported mirror -> user clone ^-----------------------/ Users push directly to upstream, and that content is then imported into the mirror. However, those repositories are not the same; it's possible that the mirroring has either broken completely, or an import process is running and not yet complete. In those cases, 'hg outgoing' will list changesets that have already been pushed. Mozilla's desired behavior described in bug 5365 can be accomplished through other means (e.g. 'hg outgoing default'), preserving the consistency and meaning of 'hg outgoing'.
Fri, 15 Dec 2017 17:52:38 -0500 tests: test-pathconflicts-merge.t requires symlinks
Augie Fackler <augie@google.com> [Fri, 15 Dec 2017 17:52:38 -0500] rev 35437
tests: test-pathconflicts-merge.t requires symlinks Once we're ready to turn this functionality on more widely, we might want to write a symlink-free version of the test that can run on Windows, but for now we'll just leave it disabled there. Differential Revision: https://phab.mercurial-scm.org/D1710
Thu, 14 Dec 2017 14:31:57 +0000 sshpeer: allow for additional environment passing to ssh exe
Kostia Balytskyi <ikostia@fb.com> [Thu, 14 Dec 2017 14:31:57 +0000] rev 35436
sshpeer: allow for additional environment passing to ssh exe We already have the ability to customize the ssh command line arguments, let's add the ability to customize its environment as well. Example use-case is ssh.exe from Git on Windows. If `HOME` enviroment variable is present and has some non-empty value, ssh.exe will try to access that location for some stuff (for example, it seems for resolving `~` in `.ssh/config`). Git for Windows seems to sometimess set this variable to the value of `/home/username` which probably works under Git Bash, but does not work in a native `cmd.exe` or `powershell`. Whatever the root cause, setting `HOME` to be an empty string heals things. Therefore, some distributors might want to set `sshenv.HOME=` in the configuration (seems less intrusive that forcing everyone to tweak their env). Test Plan: - rt Differential Revision: https://phab.mercurial-scm.org/D1683
Wed, 13 Dec 2017 17:03:39 -0800 unamend: allow unamending if allowunstable is set
Martin von Zweigbergk <martinvonz@google.com> [Wed, 13 Dec 2017 17:03:39 -0800] rev 35435
unamend: allow unamending if allowunstable is set I don't see why unamend should be disallowed when allowunstable is set. By switching to rewriteutil.precheck() we fix that and get more consistent error messages (and some additional ones). Differential Revision: https://phab.mercurial-scm.org/D1682
Wed, 13 Dec 2017 10:29:22 -0800 rebase: add ui.log calls for whether IMM used, whether rebasing WCP
Phil Cohen <phillco@fb.com> [Wed, 13 Dec 2017 10:29:22 -0800] rev 35434
rebase: add ui.log calls for whether IMM used, whether rebasing WCP Make it a bit easy to get metrics from these. Differential Revision: https://phab.mercurial-scm.org/D1681
Mon, 11 Dec 2017 17:02:02 -0800 lfs: using workers in lfs prefetch
Wojciech Lis <wlis@fb.com> [Mon, 11 Dec 2017 17:02:02 -0800] rev 35433
lfs: using workers in lfs prefetch This significantly speeds up lfs prefetch. With fast network we are seeing ~50% improvement of overall prefetch times Because of worker's API in posix we do lose finegrained progress update and only see progress when a file finished downloading. Test Plan: Run tests: ./run-tests.py -l test-lfs* .... # Ran 4 tests, 0 skipped, 0 failed. Run commands resulting in lfs prefetch e.g. hg sparse --enable-profile Differential Revision: https://phab.mercurial-scm.org/D1568
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 tip