Summary:
In PHP 8.1, the strtolower() function no longer accepts NULL.
Without this change, getMatchSeverity() exits early if there is no severity found.
Closes T15257
Ref T15190
Test Plan: I ran this with an arc linter on a private repository which doesn't have a regex to match severity
Reviewers: O1 Blessed Committers, valerio.bozzolan
Reviewed By: O1 Blessed Committers, valerio.bozzolan
Subscribers: speck, tobiaswiese, valerio.bozzolan, Matthew, Cigaryno
Maniphest Tasks: T15257, T15190
Differential Revision: https://we.phorge.it/D25126
Summary:
This change fixes 'arc patch' in some circumstances.
Closes T15254
Test Plan: I was able to run "arc patch D25111" without issues
Reviewers: O1 Blessed Committers, Matthew
Reviewed By: O1 Blessed Committers, Matthew
Subscribers: speck, tobiaswiese, Matthew, Cigaryno
Maniphest Tasks: T15187, T15254
Differential Revision: https://we.phorge.it/D25123
Summary:
Use the name "Phorge" as the defined platform.
Also prepare to rename the core library "phorge" rather then "phabricator" - see next diff.
T15006
Test Plan: Deployed change, tooltip for "Config" shows "Configure Phorge"
Reviewers: O1 Blessed Committers, speck
Reviewed By: O1 Blessed Committers, speck
Subscribers: speck, tobiaswiese, valerio.bozzolan, Matthew
Maniphest Tasks: T15006
Differential Revision: https://we.phorge.it/D25046
Summary:
Ref T13588. "arc-ls-markers" emits a "branch-state" marker so callers can identify which branch is active in the working copy.
This marker doesn't have an associated commit, so trying to generate a display name fails under stricter PHP 8.1 rules when we try to `substr(null, ...)`.
Don't attempt to generate a display name for markers with no commit hash.
Test Plan:
- Ran `arc branches` under PHP 8.1 in a Mercurial repository.
- Before: fatal.
- After: sensible output.
Maniphest Tasks: T13588
Differential Revision: https://secure.phabricator.com/D21825
Summary: Ref T13588. Additional PhutilURI fixes for PHP 8.1.
Test Plan: Ran "arc unit --everything" in Phabricator.
Maniphest Tasks: T13588
Differential Revision: https://secure.phabricator.com/D21822
Summary: Ref T13603. This is just a small piece of cleanup I've wanted to do for a while: different languages might have different list separators and repeating this implosion manually all over the place is a bit ugly even if the beahvior is never a function of translation language.
Test Plan: See next change.
Maniphest Tasks: T13603
Differential Revision: https://secure.phabricator.com/D21814
Summary:
Ref T13675. When a process daemonizes, it needs to close these actual file descriptors, so the calling context must provide them.
Elsewhere, modify the embedded "arc" to provide them. Then use them in place of reopening the streams.
Test Plan: Ran locally with embedded "arc", will deploy for production hangs.
Maniphest Tasks: T13675
Differential Revision: https://secure.phabricator.com/D21804
Summary:
Ref T13676. With increased PHP8.1 strictness around null, it seems reasonable to add some convenience parsing to "PhutilArgumentParser".
Add a helper function for parsing integers.
Test Plan:
See next change. Tried these arguments:
```
--count ''
--count asdf
--count 0
--count -3
--count 999999999999999999999999999999999999999999999234
--count 5
```
Got sensible parsing and appropriate feedback in all cases.
Maniphest Tasks: T13676
Differential Revision: https://secure.phabricator.com/D21799
Summary: Ref T13676. Ref T13588. These properties on PhutilURI have flexible types, just wrap them.
Test Plan: Built a new Drydock working copy with an HTTPS URI under PHP 8.1, see T13676.
Maniphest Tasks: T13676, T13588
Differential Revision: https://secure.phabricator.com/D21798
Summary:
Ref T13675. Ref T13556. The "STDOUT" and "STDERR" constants are defined by the PHP CLI SAPI, in `cli_register_file_handles()`.
The "native arc" embedded PHP wrapper doesn't define these, and there's no real reason to define them, since they're just defined in terms of the PHP stream wrappers ("php://stdin", etc) anyway.
This patch isn't exhaustive (and a subsequent change should add lint, rejecting these magic constants) but is just trying to make native `arc` functional.
Test Plan: Created this revision with a standalone native `arc` binary.
Subscribers: cspeckmim
Maniphest Tasks: T13675, T13556
Differential Revision: https://secure.phabricator.com/D21794
Summary:
Ref T13658. The lint rule called "getStringLiteralValue()", which produces string literals for fewer nodes than "evalStatic()".
Switch to "evalStatic()", then fix new warnings.
Test Plan:
This test plan is non-exhaustive.
- Ran "arc lint --everything --output summary" to generate new warnings.
Maniphest Tasks: T13658
Differential Revision: https://secure.phabricator.com/D21776
Summary:
Ref T13658. Remove all product name literals from "pht()" strings, by replacing them with generic text where that feels reasonably natural, or "PlatformSymbols" calls elsewhere.
These calls were identified with `arc lint --everything` after enabling the lint rule in D21763.
Test Plan: Read strings, ran "arc".
Maniphest Tasks: T13658
Differential Revision: https://secure.phabricator.com/D21764
Summary:
Ref T13658. One challenge in forking Phabricator is product name references in user-visible strings, particularly in "pht()".
Add a linter to identify the use of product name literals in "pht()" text.
The linter could fix these automatically, but it looks like there are fewer than 200 across both Arcanist and Phabricator and some sampling suggests that many are probably clearer when rewritten into generic language anyway.
Test Plan: Ran linter, saw it pop out reasonable warnings.
Maniphest Tasks: T13658
Differential Revision: https://secure.phabricator.com/D21763
Summary: Ref T13588. Adds "phutil_nonempty_string()" and similar methods to support PHP8.1 compatibility.
Test Plan: Added unit tests, ran unit tests.
Maniphest Tasks: T13588
Differential Revision: https://secure.phabricator.com/D21762
Summary:
Updated the mercurial script to pull the `parseurl` function from the new module if pulling from the old module fails.
Also updated pulling of `remoteopts` to follow the same pattern of fallback.
Fixes T13672
Test Plan:
Using mercurial 6.1 I ran `arc patch Dnnnnn --trace` and verified that it succeeded and in the trace output it used the `arc-ls-markers` extension.
Using mercurial 4.7 I ran `arc patch Dnnnnn --trace` and verified that it succeeded and in the trace output it used the `arc-ls-markers` extension.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin
Maniphest Tasks: T13672
Differential Revision: https://secure.phabricator.com/D21747
Summary: Ref T13588. I pointed my local `php` at PHP 8.1 and this is what I've hit so far; all these cases seem very unlikely to have any subtle behavior.
Test Plan: Ran various `arc` workflows under PHP 8.1.
Maniphest Tasks: T13588
Differential Revision: https://secure.phabricator.com/D21742
Summary:
Ref T13588. "each()" has been a bad idea for a long time, and was formally deprecated in PHP 7.2 and removed in PHP 8.0.
Catch use of "each()" in lint and reject it.
Test Plan:
Added and ran unit tests.
{F10021268}
Subscribers: cspeckmim
Maniphest Tasks: T13588
Differential Revision: https://secure.phabricator.com/D21741
Summary:
Ref T13588. See that task for discussion.
Improve behavior under PHP8.1, particularly the deprecation warning raised by calling `strlen(null)`.
Test Plan:
- Ran `arc help`, `arc branches`, `arc diff`, etc., under PHP 8.1 and PHP 7.4.
- Created this change with PHP8.1.
Maniphest Tasks: T13588
Differential Revision: https://secure.phabricator.com/D21740
Summary:
This default CA bundle file hasn't been updated since 2016. Update it to the current cURL extraction.
I believe this is notably impactful because of a new "Let's Encrypt" certificate, but didn't hunt down the particulars.
Test Plan:
Confirmed the hash matches the published hash:
```
$ openssl dgst -sha256 resources/ssl/default.pem
SHA256(resources/ssl/default.pem)= ae31ecb3c6e9ff3154cb7a55f017090448f88482f0e94ac927c0c67a1f33b9cf
```
This assurance is fairly meaningless since both the hash and file are published on `curl.se`. It didn't get corrupted by stellar radiation before it made it into Git, at least?
Differential Revision: https://secure.phabricator.com/D21739
Summary: Ref T13653. This entirely exists to support converging into the right swap state in deployment workflows.
Test Plan: Ran unit tests.
Maniphest Tasks: T13653
Differential Revision: https://secure.phabricator.com/D21733
Summary: Ref T13630. Piledriver cares about EBS error specifics; expand this class a bit to expose more error information.
Test Plan: Created and destroyed resource piles with Piledriver control code, elsewhere.
Maniphest Tasks: T13630
Differential Revision: https://secure.phabricator.com/D21732
Summary:
Author field is formatted with csprintf, which would be appropriate
if the resulting string was concatenated into a shell command as a
string -- but because the flags are passed as a vector of strings
and not parsed by the shell, this results in extraneous shell
quoting making it into to author field. In particular this
renders my name as D'\''Anna instead of D'Anna
Test Plan:
Performed 'arc patch' with and without these changes, confirmed
that my apostrophe was no longer mangled by shell quotes in the
resulting commit.
Reviewers: O1 Blessed Committers, speck
Reviewed By: O1 Blessed Committers, speck
Subscribers: MacFan4000, Ekubischta, speck, tobiaswiese, valerio.bozzolan
Differential Revision: https://we.phorge.it/D25026
Summary:
Refs T13665
In the update to D21716 the `str_starts_with` function was added which is only available in PHP 8. This changes it to use `strncmp()` which is compatible back to PHP 4.
Additionally fixed running into an error when trying to run `arc amend` on a commit which already matches the content known in Phabricator. Mercurial throws an error when running `amend` without file changes and using the exact same commit message it already has.
Test Plan:
I created a commit and revision then used `hg amend -e` to modify the commit message locally.
I used `arc amend` to update the commit message back to the appropriate message from Phabricator.
I ran `arc amend` again to verify that the command did not fail even though the commit message is unchanged.
I ran `arc inspect --explore -- 'commit(674492bb460)'` and verified it matched the appropriate commit, to verify the substring matching works properly.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T13665
Differential Revision: https://secure.phabricator.com/D21723
Summary:
Mercurial does not have an implementation for querying commit symbol hardpoints, which is what the "arc amend" workflow uses.
This provides an implementation for Mercurial as well as updating `ArcanistMercurialAPI` to specify the current working directory symbol as `.`.
Additionally removed an erroneous early return in `ArcanistAmendWorkflow` which prevents a check against uncommitted changes.
Fixes T13665
Test Plan:
1. I created a diff on a Mercurial revision.
2. I updated the revisions summary in phabricator.
3. I ran `arc amend` and it successfully amended the local commit with the updated commit message.
4. I modified a file in the repository and left the change uncommitted.
5. I ran `arc amend` and verified that it reported an error due to uncommited commits.
I ran the following commands to verify that they resolved to the correct commits
1. `arc inspect --explore -- 'commit(674492bb460)'` properly matched the right commit as a commit hash prefix
2. `arc inspect --explore -- 'commit(674492bb4606666d5321feb38d2a467a8733c786)'` properly matched the right commit as a full commit hash
3. `arc inspect --explore -- 'commit(master)'` properly matched the right commit as a bookmark
4. `arc inspect --explore -- 'commit(tip)'` properly matched the right commit as a tag
5. `arc inspect --explore -- 'commit(.)'` properly matched the right commit as the working directory
6. `arc inspect --explore -- 'commit(cafe)'` properly matched the right commit as a commit hash prefix
7. I created a 'cafe' bookmark on a changeset
8. `arc inspect --explore -- 'commit(cafe)'` properly matched the right commit as a bookmark
9. `arc inspect --explore -- 'commit(67449)'` properly matched the right commit as a revision number
10. `arc inspect --explore -- 'commit(2147483648)'` properly did not match any revision (no python exception)
11. `arc inspect --explore -- 'commit(0)'` properly matched the first commit
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T13665
Differential Revision: https://secure.phabricator.com/D21716
Summary:
Reported at the phorge project (https://we.phorge.it/D25017), running `arc liberate` fails on PHP 8 due to the `log()` function using `fwrite()` incorrectly assuming a format pattern can be used.
This updates to remove most of these status messages are they are largely uninformative and instead we can report progress.
- Remove the `--quiet` argument
- Always display the progress
- Remove all informational/status log statements
Test Plan:
Tested using both PHP 7.3 and PHP 8:
1. I ran `arc liberate` and saw the standard output:
```lang=console
SCAN Searching for libraries in the current working directory...
WORK Updating library: src/
Done.
DONE Updated library.
```
2. I ran deleted `phabricator/src/.phutil_module_cache` and ran `arc liberate /src`, verifying that progress was displayed while the map was computed.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D21718
Summary:
Ref T13666. Currently, "PhabricatorRepository->newConduitFuture()" sometimes returns a real "ConduitFuture" (when repository clustering is configured) and sometimes returns a degenerate "ImmediateFuture" (when repository clustering is not configured).
To populate the "ImmediateFuture", the Conduit method is called inline without any special exception handling. This means that the two pathways have significantly different exception behavior:
- On the "ImmediateFuture" pathway, the "newConduitFuture()" method itself may raise an exception related to resolving the call (e.g., invalid parameters).
- On the "ConduitFuture" pathway, exceptions are raised only once the future is "resolve()"'d.
The second behavior is the correct behavior (and the primary behavior of upstream test environments, since all my stuff and the Phacility stuff is clustered).
Prepare to put both pathways on the second behavior by introducing a "MethodCallFuture", which can move the `$conduit_call->execute()` call (and thus its exception handling) to future resolution time.
See also the followup diff in Phabricator to actually enact this change.
Test Plan: Added unit tests and made them pass, see also next change.
Reviewers: cspeckmim
Reviewed By: cspeckmim
Maniphest Tasks: T13666
Differential Revision: https://secure.phabricator.com/D21720
Summary:
`arc liberate` has been broken for a while because the `log` function attempts to call `fwrite` (whose third argument is an integer length) instead of `fprintf`. I think maybe PHP 5 was more lenient about this? Anyway, this bug makes other development somewhat tricky.
The arcanist source in general seems to be split between `fwrite(STDERR, $message."\n")` and `fprintf(STDERR, "%\n", $message)`; I decided to go with the latter.
This is sort of a test balloon on submitting diffs to Phorge. Please feel free to let me know if there's anything you'd like done differently!
Test Plan: Ran `arc liberate` to regenerate source maps and didn't get any errors
Reviewers: O1 Blessed Committers, eax
Reviewed By: O1 Blessed Committers, eax
Subscribers: chris, speck, tobiaswiese
Differential Revision: https://we.phorge.it/D25017
Summary: Ref T13659. I don't think this name actually matters since Mercurial doesn't care what the extension name is, but be a little more consistent.
Test Plan: Ran "arc land ..." and saw it run "arc-hg" commands. There's no behavioral change here: Mercurial loads the extension and runs fine no matter what name we provide.
Reviewers: cspeckmim
Reviewed By: cspeckmim
Maniphest Tasks: T13659
Differential Revision: https://secure.phabricator.com/D21711
Summary:
Refs T13659, D21697.
I suppose I missed these cases.
Test Plan:
- I ran `arc land --test` and verified the rebase used by `ArcanistMercurialLandEngine` was run with the flag to enable the extension.
```
$ hg --encoding utf-8 --config 'extensions.rebase=' rebase --dest 2fd68f4c48aaab9f6d5613b90e60b8219a9af0ae --rev 6132da63090c2c8a8d479aaae7b20497dda3e8fd..6132da63090c2c8a8d479aaae7b20497dda3e8fd --logfile - --keep --collapse
```
- I modified the merging to throw an exception before writing to the future's stdin and verified that after `arc` completed there was no rebase active.
- I set up 3 dependent diffs and landed the middle revision and verified the first and second revisions landed but not the tip revision and there were no errors and the resulting working directory was correct.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin
Maniphest Tasks: T13659
Differential Revision: https://secure.phabricator.com/D21706
Summary: This short-lived function never did anything more interesting than "phlog()" and never found a role. The last callsite for this function was removed in D330 in 2011.
Test Plan: Grepped for "phutil_deprecated()", found no callsites.
Differential Revision: https://secure.phabricator.com/D21704
Summary: Fixes T13660. See also D21703. The most desirable modern API here is "resolve()", so deprecate the similar "execute()".
Test Plan:
- Grepped for callsites.
- Ran `arc patch --trace` in a Git working copy and saw the updated "git apply" in the trace output.
- Used this test script (changing the method and the command invoked) to confirm that success and error behavior is identical in "resolve()" and "execute()", except that "execute()" now emits a deprecation warning:
```
<?php
require_once 'support/init/init-script.php';
$err = id(new PhutilExecPassthru('lsx'))->execute();
var_dump($err);
```
Reviewers: cspeckmim
Reviewed By: cspeckmim
Maniphest Tasks: T13660
Differential Revision: https://secure.phabricator.com/D21705
Summary:
Currently there are a number of `--config extensions.blah=` sprinkled throughout the Mercurial APIs which aren't pleasant to look at. Additionally it turns out the `rebase` command requires the `rebase` extension which is not turned on by default. Uses of `rebase` should also be including this flag to enable the extension when it's in use.
This adds `ArcanistMercurialAPI::buildMercurialExtensionCommand()` which allows running a Mercurial command that requires an extension just by naming the extension instead of providing the full `--config..` argument.
It can be used e.g.
```lang=php
$api->execxLocalWithExtension(
'strip',
'strip --rev %s --',
$rev);
$api->execxLocalWithExtension(
'arc-hg',
'arc-amend --logfile %s',
$tmp_file);
```
Which produces
```lang=console
$ hg --encoding utf-8 --config 'extensions.strip=' strip --rev 82567759e2d703e1e0497f5f41363de3a1500188 --
$ hg --encoding utf-8 --config 'extensions.arg-hg=/Users/cspeckrun/Source/phacility/arcanist/support/hg/arc-hg.py' arc-amend --logfile /private/var/folders/cg/364w44254v5767ydf_x1tg_80000gn/T/6bwck66ccx0kwskw/89989-5F8JaL
```
Refs T13659
Test Plan: I ran through several scenarios of running `arc diff` and `arc land` with uncommitted changes on non-head commits, while not having the `evolve` extension enabled. Using the `--trace` argument I verified that `rebase`, `strip`, `arc-amend`, and `arc-ls-markers` were all invoked and the corresponding `arc diff` and `arc land` commands succeeded. I also ran `arc land --onto-remote default` while `arc-hg.py` raised an exception for the "remote" case and verified that the error was caught by Arcanist and displayed the error and prevented further execution. I removed the error from `arc-hg.py` and re-ran the command and verified it succeeded.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T13659
Differential Revision: https://secure.phabricator.com/D21697
Summary:
Update `PhutilInteractiveEditor` to allow specifying a "task message" which will be displayed just prior to launching the user's editor.
Refs T3271
Test Plan: I ran several `arc diff` commands in varying states to invoke my editor and verified that it printed out the text indicating that my editor was being launched.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin
Maniphest Tasks: T3271
Differential Revision: https://secure.phabricator.com/D21700
Summary:
After `arc diff` creates a revision in Phabricator it amends the commit to include a link to the revision in the commit message. For Mercurial this is done with `hg commit --amend --logfile` however this will fail when trying to create a diff for a non-head commit.
This updates `ArcanistMercurialAPI::amendCommit()` to allow amending a non-head commit in two ways, depending on whether `evolve` is in use:
No evolve:
1. Rebasing the current commit onto the current commit's parent, using the new commit message
2. Rebasing all children + descendants of the current commit onto the new resulting commit
3. Stripping the original commit
With evolve:
1. Amend the commit with `hg amend --logfile`
2. Run `hg evolve` to tidy up all commits
Test Plan:
I created 6 commits in a row placing a bookmark at commits 2 `bookmark1`, 4 `bookmark2`, and 6 `bookmark3`, and ensured I had `arc:bookmark` in my base ruleset.
No evolve, non-head changeset:
1. I verified I did not have `evolve` enabled by running `hg debugextensions` and did not see `evolve` in the listed active extensions.
2. I updated to `bookmark1` and modified a file to leave a dirty working state.
3. I ran `arc diff` and when prompted to amend my changes I said "yes", and verified a phab revision was created properly.
4. I checked the status of my repository and verified it was still linear and the bookmarks pointed to the proper commits.
5. I ran `hg log -r bookmark1 --template {desc}` to view the full commit message and verified it contained both `Summary: ...` and `Differential Revision: https://...`.
6. I ran `hg diff -c bookmark1` and verified the changes for that commit included the changes I made in step 2.
No evolve, head changeset:
1. I updated to `bookmark3` which is the head commit and modified a file to leave a dirty working state.
2. I ran `arc diff` and when prompted to amend my changes I said "yes", and verified a phab revision was created properly.
3. I checked the status of my repository and verified it was still linear and all the bookmarks pointed to the proper commits.
4. I ran `hg log -r bookmark3 --template {desc}` to view the full commit message and verified it contained both `Summary: ...` and `Differential Revision: https://...`.
5. I ran `hg diff -c bookmar3` and verified the changes for that commit included the changes I made in step 1.
With evolve:
1. I enabled `evolve` and verified it was enabled by running `hg debugextensions` and saw `evolve` in the listed active extensions.
2. I updated to `bookmark2` and modified a file to leave a dirty working state.
3. I ran `arc diff` and when prompted to amend my changes I said "yes", and verified a phab revision was created properly.
4. I checked the status of my repository and verified it was still linear and all the bookmarks pointed to the proper commits.
5. I ran `hg log -r bookmark2 --template {desc}` to view the full commit message and verfieid it contained both `Summary: ...` and `Differential Revision: https://...`.
6. I ran `hg diff -c bookmark2` and verified the changes for that commit included the changes I made in step 2.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D21686
Summary:
Refs T13546
**Behavior Changes**
1. Currently, after landing the `--onto` bookmark will not be advanced to the newly pushed commit(s)
- This updates so that after pushing commits upstream, onto-marker bookmarks are pulled back from the server to retrieve their updated state
2. Currently, after landing the working directory will typically be the old `--onto` commit
- This updates the behavior in the following ways
1. If the starting working state is a commit that is part of a revision being landed, the post-land state will be the newly published commit for that revision
2. If the starting working state is a commit for a tip revision being landed and there is only a single `--onto` target, the post-land state will be the newly published commit and the `--onto` bookmark will be activated, if applicable. If there are multiple `--onto` targets defined (uncommon) then the resulting working state will be the same behavior as before, as the desired behavior for this case is ambiguous.
3. If the starting working state is a commit that is not part of any revision being landed, then the post-land state will be that same commit, activating the same previous bookmark if applicable.
**Bugs Fixed**
1. When landing a diff that includes multiple commits, where the non-tip commit adds a file and later commit modifies that file, the land process would fail during rebasing.
2. When landing, the display of what commits are going to be landed only includes the commit hash but should include part of the commit message for easy identification.
3. If errors occur during a rebase while landing, the resulting state is an in-progress rebase. Users will typically not be able to resolve this in-progress rebase and possibly confuse them further as they have to first abort the rebase before trying to clean up. These rebases will now be aborted by arcanist before exiting.
4. If using evolve, landing a non-tip revision would leave behind orphaned commits.
Test Plan:
Bookmark test
- I created a diff with bookmark `test`, as a branch from before the `master` commit
- I updated working state to activate `test`
- I landed that diff
- I verified that the resulting working state was on the newly published `master` commit
Non-bookmark test
- I created a diff with bookmark `test`, as a branch from before the `master` commit
- I updated working state to be the new commit, but not activate `test` even though it points to that same commit
- I landed that diff
- I verified that the resulting working state was on the newly published `master` commit
Not-working state test
- I created a diff with bookmark `test`, as a branch from before the `master` commit
- I updated working state to an older commit not related to the one being landed
- I landed that diff
- I verified the ending resulting working state was on the older commit I was on prior to landing
Multiple commits test
- Using `test` bookmark I created a commit that added a new file, made a diff, made another new commit on top of it which modified that file, then updated the diff
- I updated my working state to the first commit for the diff (non-head)
- I ran `arc land test` to land the diff
- I verified that the resulting working state was on the newly published `master` commit
Landing while on `master`
- I created a diff with a bookmark `test`, as a branch from before the `master` commit
- I updated working state to the `master` bookmark
- I landed that diff
- I verified that the resulting working state was on the newly published `master` commit
Landing with no local `master` bookmark
- I created a diff consisting of two commits with bookmark `test`, as a branch from before the `master` commit
- I left working state on `test` and deleted my local `master` bookmark
- I landed that diff
- I verified that the resulting working state was on the newly published `master` commit and the `master` bookmark was pulled and active
Cascading diffs while on an earlier diff changeset
- I setup two diffs, each consisting of two commits, one depending on the other
- I put the working state onto a commit from the earlier diff
- I landed the later diff
- I verified that the resulting working state was on the newly published commit associated with the earlier diff, which is not the new `master` commit so there was no active bookmark
Cascading diffs while on the later diff changeset
- I setup two diffs, each consisting of two commits, one depending on the other
- I put the working state into a commit from the later diff
- I landed the later diff
- I verified that the resulting working state was on the newly published commit for the later diff which was `master` and `master` was active
Landing a non-tip revision, with evolve
- I setup three diffs, each consisting of two commits, creating a dependency chain
- I verified I had the evolve extension enabled via `hg debugextensions`
- I put the working state on a commit in the first revision
- I landed the second revision
- I verified that the resulting working state was clean, that revisions 1 and 2 were properly landed and published, and the resulting working state was on the published commit for the first revision.
Landing a non-tip revision, without evolve
- I setup three diffs, each consisting of two commits, creating a dependency chain
- I verified I did not have the evolve extension enabled via `hg debugextensions`
- I put the working state on a commit in the first revision
- I landed the second revision
- I verified that the resulting working state was clean, that revisions 1 and 2 were properly landed and published, and the resulting working state was on the published commit for the first revision.
Landing a non-tip revision, while the non-landing revision is active
- I setup three diffs, each consisting of two commits, creating a dependency chain
- I put the working state on the latest tip revision commit and its bookmark
- I landed the second revision
- I verified that revisions 1 and 2 were properly landed and published, and the resulting working state was still on the latest tip revision commit and its bookmark was active.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21680
Summary:
Refs D21679 (phabricator changes)
This updates Arcanist to be able to check whether the version of Mercurial supports using `{p1.node}` template format vs. `{p1node}`.
Test Plan: Tested under coverage from D21679
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D21681
Summary:
When non-ascii characters appear in revision titles/summaries the `patch` and `diff` (to update) commands will fail on Windows systems. This often occurs due to “smart quotes” or "em—dash" characters being inserted into commit messages by editors on "user-friendly" operating systems like macOS.
This can be worked around by forcing all mercurial commands to use the global option `--encoding utf-8` which applies for any mercurial command. This option was [[ https://www.mercurial-scm.org/repo/hg/rev/a88e02081a88 | added in ~2006 ]] so this should work across all supported versions of mercurial.
Refs T13649
Test Plan:
I created a diff on a mercurial repository using smart quotes in the "Title" and "Summary" fields as well as in the content of a file being changed. Then on macOS, Windows (PowerShell), and Windows (cmd.exe) I was able to `patch` down the revision, make a modification, and `diff` the change back up to Phabricator, as well as `land` the change. I verified the commit and content looked correct on macOS as well as on Windows by using `nvim` which seems to properly detect and render the encoding, whereas mercurial displays the smart quotes and em-dashes with odd characters instead.
I did a grep through Arcanist codebase to find other places where `--encoding` might be specified for mercurial commands and could not find any. In the event that somehow this argument is added elsewhere I verified that multiple specifications of `--encoding utf-8` does not cause any issues and the later specification of `--encoding` appears to "win".
```lang=console
$ hg --encoding utf-8 --encoding utf-8 log -r tip
# prints out results in UTF-8 without issue
$ hg --encoding utf-8 log --encoding latin-1 -r tip
# prints out results in latin-1 without issue
```
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin
Maniphest Tasks: T13649
Differential Revision: https://secure.phabricator.com/D21676
Summary:
Updated .arcconfig to we.phorge.it
Refs T15006
I would also note, I created this revision using the container setup developed by @willson556 mentioned in T15011#370 and it worked great!
Test Plan:
Ran `arc install-certificate` and was able to get token from the right place and install it
Ran `arc which` saw that it identified `we.phorge.it`
Reviewers: speck, avivey, tobiaswiese, O1 Blessed Committers, eax, #blessed_committers
Reviewed By: speck, avivey, tobiaswiese, O1 Blessed Committers, eax, #blessed_committers
Subscribers: deadalnix, chris, willson556, speck
Maniphest Tasks: T15006
Differential Revision: https://we.phorge.it/D25003
Summary: See PHI2085. Python 3 is stricter about integers and floats than Python 2 was, and we can end up passing a float where an integer was expected if the player wins "arc anoid" using a terminal with certain (most?) character dimensions.
Test Plan:
- Modified "arcanoid.py" to win instantly.
- Adjusted terminal window to 80x24, ran "arc anoid", reproduced crash.
- Ran "python2 arcanoid.py" and observed old victory animation behavior.
- Applied patch.
- Ran "arc anoid" and observed identical victory animation behavior.
Differential Revision: https://secure.phabricator.com/D21667
Summary:
Ref T13649. Currently, "arc" may leave stdin nonblocking after showing a prompt. This can cause various odd behaviors down the line.
I can't immediately reproduce this behavior on macOS in "zsh" or "bash" (I'm unable to get stdin to remain nonblocking beyond the process lifespan), and also don't have pcntl locally so there's a fair amount of handwaving here.
Test Plan: This is somewhat speculative since I can't immediately reproduce the behavior. I tested the locally-reachable paths (no pcntl) but they're not interesting.
Maniphest Tasks: T13649
Differential Revision: https://secure.phabricator.com/D21666
Summary:
Ref T13562. Currently, "Filesystem::copyFile()" uses "copy", which doesn't work now that we no longer invoke "cmd.exe" by default.
Use "copy()" instead.
Note that this whole function is probably nonsense, but I'll follow up on T13562.
Test Plan:
- Created a standalone script which runs "Filesystem::copyFile()".
- Before: failed to copy any file.
- After: succesfully copied normal files.
- After: failed to copy a file over an existing directory with a reasonable error.
- After: failed to copy a file over itself with a reasonable error.
Maniphest Tasks: T13562
Differential Revision: https://secure.phabricator.com/D21643
