The stalled transactions on this host published after I deployed the update.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 22 2021
Jul 21 2021
These keep springing up
(After picking up D21697, the approach works properly in my environment where I originally ran into this, but there are a couple of rebase calls still present in ArcanistMercurialLandEngine that don't use the new API yet.)
I just use TextMate, which is a fairly lightweight editor. I have it minimally configured to disable a couple of default behaviors and add a couple aliases, and I have a crude "jump-to-definition" script set up that tries to open whatever file defines the class/function under the cursor and succeeds about 95% of the time.
Do you use an editor like PHPStorm or WebStorm? So far I've been using SublimeText and ripgrep as the primarily tools.
...the one with --onto-remote default not appearing in the trace output...
- Updated the MercurialMarkerQuery to use a similar execPassthruWithExtension(). This results in printing the execution with --trace and better encapsulates the functions handling the extension-enabling details.
- Made newConfiguredFuture() to combine the environment/cwd configuration for mercurial executions.
- Updated to store result of func_get_args() into a variable first instead of passing directly into a function call.
- Updated comments.
Oh I forgot to include that it does launch the regular local version of arc-ls-markers in my sample output, which may have provided more context for my comment about the one with --onto-remote default not appearing in the trace output
...or did you mean something else?
Specifically the arc-ls-markers which uses the --output argument, which appears to only be used when a remote marker is specified for landing. That uses $api->newPassthru(). When checking the output from arc land --onto-remote default it doesn't appear to log the execution of the passthru.
Thanks! Couple of minor inlines but I didn't catch anything substantial.
On a non-head dirty commit I ran arc diff --trace and could confirm these ran properly
$ 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/cglmx89uf3ks4gow/45330-yqYFDu
Simplify some of the code by splitting out the bit which produces the flag to enable the extension and the bit that combines everything into an array of arguments to be passed into e.g. execxLocal().
Okay I think this is ready for review. I'm not too certain I'm handling the command pattern population properly but I learned more about PHP reflection.
This happens when a recipient list includes an Owners package which has been destroyed. Specifically, we'll exit this section of PhabricatorMetaMTAMemberQuery with out the PHID in $package_map, and then fail to return it:
Oh, maybe I'm mixing up running arc diff B against running plain arc diff while being on B
Marking this as resolved by D21700. If there are further details or input we can re-open to further address.
Update formatting