Wed, 15 Apr 2020 20:08:36 +0200 wait-on-file: don't quote arithmetic argument
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Apr 2020 20:08:36 +0200] rev 44726
wait-on-file: don't quote arithmetic argument This is unnecessary and Mac OS X choke on them. Differential Revision: https://phab.mercurial-scm.org/D8425
Tue, 14 Apr 2020 19:09:56 -0400 graft: exit 1 on conflicts, like merge
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Tue, 14 Apr 2020 19:09:56 -0400] rev 44725
graft: exit 1 on conflicts, like merge It's more consistent, and makes it nicer to script around hg if you don't have to ignore exit code 255, which is the error code for basically everything in hg. Differential Revision: https://phab.mercurial-scm.org/D8423
Fri, 10 Apr 2020 19:58:34 +0200 tests: deal with "ls" vs "ls -A" difference on 2BSD derived systems
Joerg Sonnenberger <joerg@bec.de> [Fri, 10 Apr 2020 19:58:34 +0200] rev 44724
tests: deal with "ls" vs "ls -A" difference on 2BSD derived systems BSD-derived systems will use "ls -A" when running as root. Adjust the test cases to always use the flag and include .hg and related output as appropiately. Differential Revision: https://phab.mercurial-scm.org/D8397
Fri, 10 Apr 2020 19:53:36 +0200 tests: skip non-readable check for root
Joerg Sonnenberger <joerg@bec.de> [Fri, 10 Apr 2020 19:53:36 +0200] rev 44723
tests: skip non-readable check for root Trying to check for errors on non-readable hgrc requires UNIX permissions, but still won't work for root. So adjust the check. Differential Revision: https://phab.mercurial-scm.org/D8396
Fri, 10 Apr 2020 19:52:33 +0200 tests: skip CVS tests for root
Joerg Sonnenberger <joerg@bec.de> [Fri, 10 Apr 2020 19:52:33 +0200] rev 44722
tests: skip CVS tests for root It is not uncommon for cvs to check for root and to refuse work in that case. Differential Revision: https://phab.mercurial-scm.org/D8395
Wed, 15 Apr 2020 22:18:05 -0400 make: drop the `-c` arg to `install` in the documentation makefile
Matt Harbison <matt_harbison@yahoo.com> [Wed, 15 Apr 2020 22:18:05 -0400] rev 44721
make: drop the `-c` arg to `install` in the documentation makefile This arg caused `gmake install` on OpenIndiana 2019.10 (illumos) fail with: install: The -c, -f, -n options each require a directory following! install: The -c, -f, -n options each require a directory following! install: The -c, -f, -n options each require a directory following! gmake[1]: *** [Makefile:41: install] Error 2 gmake[1]: Leaving directory '/usr/local/share/mercurial/doc' The workaround is to run `gmake install-bin`. The man page for 10.14 says this is to copy the file and is only for compatability, as it is the default. The CentOS 7 man page says it is ignored. The top level makefile doesn't use this argument at all, so I'm not sure why it's here. Differential Revision: https://phab.mercurial-scm.org/D8439
Tue, 14 Apr 2020 18:51:23 -0400 phabricator: restack any new orphans created by phabsend (issue6045)
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Apr 2020 18:51:23 -0400] rev 44720
phabricator: restack any new orphans created by phabsend (issue6045) Previously, posting a new review for a non head commit would orphan the head. The general case is any descendant of the selected revisions got orphaned if this was the first time the selected revisions were submitted. It doesn't happen when resubmitting. I've already had coworkers hit this a few times and get confused. Since posting a review isn't generally thought of as an editing operation, it would probably be easier for new users if we just restacked. This avoids restacking existing orphans around the submission because that may involve merge conflict resolution. Users who already have orphans should know how to stabilize them anyway. Differential Revision: https://phab.mercurial-scm.org/D8438
Sun, 12 Apr 2020 13:11:42 -0400 phabricator: prevent posting obsolete commits
Matt Harbison <matt_harbison@yahoo.com> [Sun, 12 Apr 2020 13:11:42 -0400] rev 44719
phabricator: prevent posting obsolete commits I don't see why this would be useful in the first place. But I had a coworker submit a single commit that was not a branch head, and the result was to orphan its child and keep the original commit visible. He then did up arrow + Enter, and it happily created a new review (since the URL isn't amended into the original commit specified on the command line) and a new successor, resulting in a local divergence. I'd like to fix the issue with creating orphans, but this is simple enough to prevent on its own. Differential Revision: https://phab.mercurial-scm.org/D8437
Tue, 03 Mar 2020 17:37:09 -0500 phabricator: avoid creating unstable children within the review stack
Matt Harbison <matt_harbison@yahoo.com> [Tue, 03 Mar 2020 17:37:09 -0500] rev 44718
phabricator: avoid creating unstable children within the review stack The instability occurred when rebasing something that has already been submitted onto something that hasn't, and then resubmitting the stack. Or as the test shows, just resubmitting and including something earlier that wasn't previously submitted. There's a general case here where any children (not just the ones in the range of commits posted for review) should be re-stabilized. But handling the selected commits here will cause the `local:commit` node values that are tracked on Phabricator to be properly kept in sync. Differential Revision: https://phab.mercurial-scm.org/D8436
Wed, 08 Apr 2020 17:30:10 -0400 phabricator: add an option to fold several commits into one review (issue6244)
Matt Harbison <matt_harbison@yahoo.com> [Wed, 08 Apr 2020 17:30:10 -0400] rev 44717
phabricator: add an option to fold several commits into one review (issue6244) Now that all of the pieces are in place, alter the user facing command to allow it. This is the default behavior when using `arc`, but I much prefer the 1:1 approach, and I'm tempted to mark this advanced to limit its abuse. I started out calling this `--no-stack` like the feature request suggested, but I found it less obvious (especially when writing the code), so I went with the `hg fold` analogue. This will populate the `Commits` tab in the web UI with the hash of each commit folded into the review. From experimentation, it seems to list them in the order they are received from the extension instead of the actual parent/child relationship. The extension sends them in sorted order, thanks to `templatefilters.json()`. Since there's enough info there for them to put things in the right order, JSON is unordered aside from lists (IIUC), and there doesn't seem to be any harmful side effects, I guess we write this off as their bug. It is simple enough to workaround by putting a check for `util.sortdict` into `templatefilters.json()`, and don't resort in that case. There are a handful of restrictions that are documented in the code, which somebody could probably fix if they're interested. Notably, this requires the (default) `--amend` option, because there's not an easy way to apply a local tag across several commits. This also doesn't do preflight checking to ensure that all previous commits that were part of a single review are selected when updating. That seems expensive. What happens is the excluded commit is dropped from the review, but it keeps the Differential Revision line in the commit message. Not everything can be edited, so it doesn't seem worth making the code even more complicated to handle this edge case. There are a couple of "obsolete feature not enabled but X markers found!" messages that appeared on Windows but not macOS. I have no idea what's going on here, but that's an unrelated issue, so I conditionalized those lines. Differential Revision: https://phab.mercurial-scm.org/D8314
Wed, 08 Apr 2020 17:07:19 -0400 tests: move the phabricator auth token to the global config file
Matt Harbison <matt_harbison@yahoo.com> [Wed, 08 Apr 2020 17:07:19 -0400] rev 44716
tests: move the phabricator auth token to the global config file The next commit introduces a new repo to simplify its development. This value needs to be modified to record tests, so it doesn't make sense to have to do that twice. The callsign and URL are *not* moved because there are tests that fallback to the .arcconfig file when those aren't present. Differential Revision: https://phab.mercurial-scm.org/D8390
Sun, 05 Apr 2020 21:19:21 -0400 phabricator: add debug logging to show previous node values in `phabsend`
Matt Harbison <matt_harbison@yahoo.com> [Sun, 05 Apr 2020 21:19:21 -0400] rev 44715
phabricator: add debug logging to show previous node values in `phabsend` This isn't real useful here, but was very useful showing how `phabsend --fold` handles commits created by `hg fold` and `hg split`. It introduces a new debug function and flag instead of using `ui.debug()`, because `--debug` prints out all of the API chatter. Differential Revision: https://phab.mercurial-scm.org/D8389
Thu, 16 Apr 2020 17:31:29 +0200 rust: update README with new information about the Re2 path
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Apr 2020 17:31:29 +0200] rev 44714
rust: update README with new information about the Re2 path Differential Revision: https://phab.mercurial-scm.org/D8452
Thu, 16 Apr 2020 17:31:11 +0200 rust: add option of static linking a local Re2 install
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Apr 2020 17:31:11 +0200] rev 44713
rust: add option of static linking a local Re2 install Previously, only dynamically linking the system-wide install was possible. We force the user to provide one to prevent hard-to-track errors. Differential Revision: https://phab.mercurial-scm.org/D8451
Wed, 15 Apr 2020 23:11:55 +0900 templatekw: cache mergestate even if merge is not ongoing
Yuya Nishihara <yuya@tcha.org> [Wed, 15 Apr 2020 23:11:55 +0900] rev 44712
templatekw: cache mergestate even if merge is not ongoing While playing with eBPF, I noticed .hg/merge/state{,2} files were tried to open() for each revision. That's not healthy. Let's cache the "inactive" state as well.
Wed, 15 Apr 2020 19:24:21 +0900 revset: remove explicit sort() from unstable()
Yuya Nishihara <yuya@tcha.org> [Wed, 15 Apr 2020 19:24:21 +0900] rev 44711
revset: remove explicit sort() from unstable() The instability should be dealt with by baseset.__init__(), and the returned smartset is ordered by 'subset &' anyway.
(0) -30000 -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 tip