Page MenuHomePhabricator

cspeckmim (Christopher Speck)
Xevioid

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Saturday

  • Clear sailing ahead.

User Details

User Since
Dec 8 2014, 6:48 PM (347 w, 2 d)
Availability
Available

Software Engineering Lead

MIM Software, Inc.

http://www.mimsoftware.com/

{F1081352}

Recent Activity

Thu, Jul 29

cspeckmim accepted D21713: Add an "eval" rule to Remarkup.
Thu, Jul 29, 8:30 PM
cspeckmim added a comment to D21713: Add an "eval" rule to Remarkup.

I think _() is the pht() of Gnu "gettext". Modern programers may mostly be more familiar with Python than with gettext, of course.

Oh yea that's right. A long time ago I worked on a python web application that used this was probably confusing it.

Thu, Jul 29, 1:03 AM
cspeckmim planned changes to D21712: Trying out removing "Phabricator" from some user-visible text.

I'll plan to get this on a test instance and get some screenshots

Thu, Jul 29, 1:01 AM
cspeckmim added inline comments to D21713: Add an "eval" rule to Remarkup.
Thu, Jul 29, 12:57 AM
cspeckmim updated the diff for D21712: Trying out removing "Phabricator" from some user-visible text.

Try escaping the ${{{

Thu, Jul 29, 12:54 AM

Wed, Jul 28

cspeckmim added a comment to D21713: Add an "eval" rule to Remarkup.

You can either escape ${{{strings.x.y}}} as \${{{strings.x.y}}} or suggest a different syntax for the "eval" rule --- I'm not married to ${{{...}}}.

I think this format makes sense to me. Nothing else really comes to mind. The squiggles are keeping consistency with other remarkup rules like figlet and cowsay. I think I've seen $ used in other places (and languages) with some relation to string substitution. I think python convention uses _, so another possibility could be _{{{...}}}.

Wed, Jul 28, 10:18 PM
cspeckmim added a comment to D21680: An assortment of fixes and updates to using arc-land with mercurial.

I’ve used this a few times in the past week and the behavior is overall better for my own case. I had one other developer upgrade to master branch and also reported better behavior, though his setup is very similar to my own.

Wed, Jul 28, 4:22 AM
cspeckmim added a comment to D21686: Update "arc diff" to amend non-head commits with Mercurial.

Adding some feedback regarding these changes (I should’ve made a task for this first). Last week I had two developers separately approach me with issues they ran into with arc diff. I had them upgrade to the master branch and this resolved their issues.

Wed, Jul 28, 4:20 AM
cspeckmim added inline comments to D21712: Trying out removing "Phabricator" from some user-visible text.
Wed, Jul 28, 4:07 AM
cspeckmim planned changes to D21712: Trying out removing "Phabricator" from some user-visible text.

I'll investigate the build failures -- I suspect it's the use of the new remarkup rule. At the moment I'm working from a Windows system and haven't been able to get xhpast or unit tests running properly.

Wed, Jul 28, 4:01 AM
cspeckmim updated the diff for D21712: Trying out removing "Phabricator" from some user-visible text.

Minor corrections

Wed, Jul 28, 3:59 AM
cspeckmim updated the diff for D21712: Trying out removing "Phabricator" from some user-visible text.

Preferring "installation" as a generic term, where possible

Wed, Jul 28, 3:54 AM
cspeckmim accepted D21713: Add an "eval" rule to Remarkup.
Wed, Jul 28, 3:11 AM
cspeckmim added a comment to D21713: Add an "eval" rule to Remarkup.

This looks pretty cool and will be useful for maintaining existing text that goes through remarkup. Really useful doc on PhutilRemarkupBlockStorage btw.

Wed, Jul 28, 3:10 AM

Tue, Jul 27

cspeckmim published D21712: Trying out removing "Phabricator" from some user-visible text for review.

This is just trying out some changes that modify the language to reduce instances of "Phabricator" from user-visible text. I went through the auth provider implementations to try out using "platform", "server", "service", and in one case I think just "instance".

Tue, Jul 27, 12:51 AM
cspeckmim added a revision to T13658: How to rebrand Phabricator: D21712: Trying out removing "Phabricator" from some user-visible text.
Tue, Jul 27, 12:44 AM

Mon, Jul 26

cspeckmim accepted D21711: Name extension as "arc-hg", not "arg-hg".

argh

Mon, Jul 26, 6:52 PM

Wed, Jul 21

cspeckmim closed D21706: Update other usages of "hg rebase" to use the new extension-enabling function.
Wed, Jul 21, 9:11 PM
cspeckmim committed rARC76a2976fd9a4: Update other usages of "hg rebase" to use the new extension-enabling function (authored by cspeckmim).
Update other usages of "hg rebase" to use the new extension-enabling function
Wed, Jul 21, 9:11 PM
cspeckmim updated the test plan for D21706: Update other usages of "hg rebase" to use the new extension-enabling function.
Wed, Jul 21, 9:11 PM
cspeckmim updated the diff for D21706: Update other usages of "hg rebase" to use the new extension-enabling function.

These keep springing up

Wed, Jul 21, 9:03 PM
cspeckmim requested review of D21706: Update other usages of "hg rebase" to use the new extension-enabling function.
Wed, Jul 21, 8:59 PM
cspeckmim added a revision to T13659: `arc land` may fail with missing rebase extension: D21706: Update other usages of "hg rebase" to use the new extension-enabling function.
Wed, Jul 21, 8:59 PM · Arcanist, Mercurial
cspeckmim accepted D21703: Use "resolve()", not "execute()", for PhutilExecPassthru callsites in Phabricator.
Wed, Jul 21, 5:18 PM
cspeckmim accepted D21705: Deprecate "PhutilExecPassthru->execute()" in favor of "resolve()".
Wed, Jul 21, 5:17 PM
cspeckmim added a comment to D21697: Refactor how Mercurial runs commands that require extensions.

Do you use an editor like PHPStorm or WebStorm? So far I've been using SublimeText and ripgrep as the primarily tools.

Wed, Jul 21, 4:56 AM
cspeckmim closed D21697: Refactor how Mercurial runs commands that require extensions.
Wed, Jul 21, 4:40 AM
cspeckmim committed rARCac365c3ee509: Refactor how Mercurial runs commands that require extensions (authored by cspeckmim).
Refactor how Mercurial runs commands that require extensions
Wed, Jul 21, 4:40 AM
cspeckmim updated the test plan for D21697: Refactor how Mercurial runs commands that require extensions.
Wed, Jul 21, 4:19 AM
cspeckmim added inline comments to D21697: Refactor how Mercurial runs commands that require extensions.
Wed, Jul 21, 4:10 AM
cspeckmim added inline comments to D21697: Refactor how Mercurial runs commands that require extensions.
Wed, Jul 21, 4:05 AM
cspeckmim updated the diff for D21697: Refactor how Mercurial runs commands that require extensions.
  • 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.
Wed, Jul 21, 4:01 AM
cspeckmim added a comment to D21697: Refactor how Mercurial runs commands that require extensions.

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

Wed, Jul 21, 3:37 AM
cspeckmim added a comment to D21697: Refactor how Mercurial runs commands that require extensions.

...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.

Wed, Jul 21, 3:36 AM
cspeckmim added a comment to D21697: Refactor how Mercurial runs commands that require extensions.

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
Wed, Jul 21, 1:54 AM
cspeckmim updated the diff for D21697: Refactor how Mercurial runs commands that require extensions.

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().

Wed, Jul 21, 1:47 AM
cspeckmim added inline comments to D21697: Refactor how Mercurial runs commands that require extensions.
Wed, Jul 21, 1:26 AM
cspeckmim published D21697: Refactor how Mercurial runs commands that require extensions for review.

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.

Wed, Jul 21, 1:15 AM
cspeckmim added a comment to D21680: An assortment of fixes and updates to using arc-land with mercurial.

Oh, maybe I'm mixing up running arc diff B against running plain arc diff while being on B

Wed, Jul 21, 12:53 AM
cspeckmim closed T3271: Before launching $EDITOR from arc, print that we're doing it, a subtask of T13098: Plans: Arcanist toolsets and extensions, as Resolved.
Wed, Jul 21, 12:37 AM · Arcanist, Plans
cspeckmim closed T3271: Before launching $EDITOR from arc, print that we're doing it as Resolved.

Marking this as resolved by D21700. If there are further details or input we can re-open to further address.

Wed, Jul 21, 12:37 AM · Arcanist
cspeckmim closed D21700: Display informative message when arc launches an editor.
Wed, Jul 21, 12:33 AM
cspeckmim committed rARC232363e387da: Display informative message when arc launches an editor (authored by cspeckmim).
Display informative message when arc launches an editor
Wed, Jul 21, 12:33 AM
cspeckmim updated the diff for D21700: Display informative message when arc launches an editor.

Update formatting

Wed, Jul 21, 12:32 AM
cspeckmim added inline comments to D21700: Display informative message when arc launches an editor.
Wed, Jul 21, 12:31 AM

Tue, Jul 20

cspeckmim added a comment to D21700: Display informative message when arc launches an editor.

Maybe the output could be two separate lines:

Launching editor ("nano")...
Supply commit message for uncommitted changes, then save and exit.

Then neither part needs to care about the other part, and things are likely more translatable and such.

Yea that works a lot better. Though I'm on the fence about the order of the two messages. Logically my brain wants the "Launching..." message to be second but I don't think it really matters

Tue, Jul 20, 10:30 PM
cspeckmim updated the diff for D21700: Display informative message when arc launches an editor.

Update the display format to not try and combine two things

Tue, Jul 20, 10:25 PM
cspeckmim added inline comments to D21700: Display informative message when arc launches an editor.
Tue, Jul 20, 10:04 PM
cspeckmim requested review of D21700: Display informative message when arc launches an editor.
Tue, Jul 20, 9:59 PM
cspeckmim added a revision to T3271: Before launching $EDITOR from arc, print that we're doing it: D21700: Display informative message when arc launches an editor.
Tue, Jul 20, 9:58 PM · Arcanist
cspeckmim closed D21686: Update "arc diff" to amend non-head commits with Mercurial.
Tue, Jul 20, 8:55 PM
cspeckmim committed rARC41f6c6ecb2ec: Update "arc diff" to amend non-head commits with Mercurial (authored by cspeckmim).
Update "arc diff" to amend non-head commits with Mercurial
Tue, Jul 20, 8:55 PM
cspeckmim added a revision to T13659: `arc land` may fail with missing rebase extension: D21697: Refactor how Mercurial runs commands that require extensions.
Tue, Jul 20, 4:36 AM · Arcanist, Mercurial
cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Remove the stdout text matching, I confirmed that using arc diff with uncommitted changes on a head changeset properly amended the change into the changeset.

Tue, Jul 20, 1:52 AM
cspeckmim added inline comments to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Tue, Jul 20, 1:39 AM
cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Revert changes to GitLocalState

Tue, Jul 20, 1:24 AM

Mon, Jul 19

cspeckmim added a comment to D21686: Update "arc diff" to amend non-head commits with Mercurial.

If the git changes are too much I can pull those out- I think a longer-term solution will be to do version-checking for whether git stash create is supported and use that instead but I can do that in a separate change.

Mon, Jul 19, 8:35 PM
cspeckmim added a comment to D21686: Update "arc diff" to amend non-head commits with Mercurial.

I really like that idea. I generalized the comments on the methods and then added a stack to GitLocalState. I ran two basic tests for this, running arc diff with uncommited changes and running arc land with uncommitted changes. For arc diff it properly amended the uncommitted changes into my diff (unsure if stash is used here), and for arc land it properly stashed my change during the land and restored it afterwards.

Mon, Jul 19, 8:33 PM
cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Update comments, include an internal stack in ArcanistGitLocalState for tracking the order of save/restore

Mon, Jul 19, 8:30 PM
cspeckmim added inline comments to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Mon, Jul 19, 6:48 PM
cspeckmim added inline comments to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Mon, Jul 19, 6:01 PM
cspeckmim added inline comments to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Mon, Jul 19, 5:55 PM
cspeckmim added a comment to T13659: `arc land` may fail with missing rebase extension.

I'm also surprised that rebase extension isn't enabled by default. I guess I have been turning it on in my default setup.

Mon, Jul 19, 5:42 PM · Arcanist, Mercurial
cspeckmim claimed T13659: `arc land` may fail with missing rebase extension.

I like that idea. I'll take a look.

Mon, Jul 19, 5:41 PM · Arcanist, Mercurial
cspeckmim added inline comments to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Mon, Jul 19, 2:36 AM
cspeckmim added a comment to D21680: An assortment of fixes and updates to using arc-land with mercurial.

Still, I'd expect arc land <head2> to look at the ancestors between head2 and master, find the "Differential Revision" commit, and then figure out that "head2" can only be part of that revision, possibly prompting you ("Local range includes commits which don't match the revision, are you sure you want to land them?").

Mon, Jul 19, 2:10 AM

Sun, Jul 18

cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Fix up comments

Sun, Jul 18, 5:04 PM
cspeckmim added inline comments to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Sun, Jul 18, 5:03 PM
cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Updating arc-amend to support some older versions of Mercurial

Sun, Jul 18, 4:48 PM
cspeckmim added inline comments to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Sun, Jul 18, 5:32 AM
cspeckmim updated the test plan for D21686: Update "arc diff" to amend non-head commits with Mercurial.
Sun, Jul 18, 4:54 AM
cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Remove unused import from arc-hg.py

Sun, Jul 18, 4:46 AM
cspeckmim added a comment to D21686: Update "arc diff" to amend non-head commits with Mercurial.

I went back to test this with Mercurial 4.0 just as a test and the extension file fails to load properly. I traced the issue down to this issue
https://stackoverflow.com/questions/52117289/simple-mercurial-extension-fails-to-import

Sun, Jul 18, 4:44 AM
cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Use arc-amend instead of a long Mercurial dance

Sun, Jul 18, 4:34 AM

Sat, Jul 17

cspeckmim added a comment to D21686: Update "arc diff" to amend non-head commits with Mercurial.

Sounds good. I spent 15 seconds on trying to write hg arc-amend, and this does something and does appear to produce an amended commit that looks ballpark-correct (and can amend non-heads), but emits some warnings and I have no clue if it functions across Mercurial versions:

diff --git a/support/hg/arc-hg.py b/support/hg/arc-hg.py
index 01ac3907..82202767 100644
--- a/support/hg/arc-hg.py
+++ b/support/hg/arc-hg.py
@@ -28,6 +28,12 @@ _ = i18n._
 cmdtable = {}
 command = registrar.command(cmdtable)
 
+@command(
+  b'arc-amend')
+def amend(ui, repo, source=None, **opts):
+  cmdutil.amend(ui, repo, repo[b'.'], {}, [], opts)
+  return 0
+
 @command(
   b'arc-ls-markers',
   [(b'', b'output', b'',

Still, it seems possible that this is the least-messy pathway for non-evolve support since we need the extension anyway and all the "can't amend non-head" stuff seems advisory rather than technical, given that flags exist to disable the checks and the low-level call seems to produce the desired repository state.

Sat, Jul 17, 1:25 AM
cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Fix some typos and comments before @epriestley spots them

Sat, Jul 17, 12:00 AM

Fri, Jul 16

cspeckmim added inline comments to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Fri, Jul 16, 11:45 PM
cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Added a workflow argument to the amendCommit() path so it can be set on the local state for logging purposes.
Fixed the issue with the terminal, Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!

Fri, Jul 16, 11:40 PM
cspeckmim added a comment to D21686: Update "arc diff" to amend non-head commits with Mercurial.

Given the mess of dealing with the non-evolve case, what do you think about splitting this into a smaller "make this work under evolve" change and landing that now (which should solve everything for your org, since everyone has evolve?) since all that code looks good to me, and then maybe revisiting the non-evolve case if it other users hit it and/or diff gets some work and it's easier, and/or we figure out a reasonable way to hg force-amend or do some other less-tortured operation here.

Unfortunately not everyone at my org uses evolve, in fact most don't. I've never gotten a solid reason for why but I suspect it's just "new" and frightening. I started looking at this change initially because someone ran into an error when trying to arc diff a non-head revision. I'll try to investigate what's happening - it totally hoses my console and I can't scroll up to view the history when using --trace so I'll have to pipe the output to a file or something. If I can't figure it out I might just throw an error stating that evolve is required here when trying to amend changes to a non-head commit. I'll extract out the non-evolve-local-changes amend to a separate function.

Fri, Jul 16, 4:54 PM
cspeckmim added inline comments to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Fri, Jul 16, 3:07 AM
cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Attempt to stash unsaved changes before doing the rebase dance. Not currently in a working state.

Fri, Jul 16, 3:03 AM
cspeckmim added a comment to D21686: Update "arc diff" to amend non-head commits with Mercurial.

You can probably stash/restore by using ArcanistMercurialLocalState, although I'm not 100% sure it's reentrancy-safe and I'd imagine arc diff may already be holding a LocalState object somewhere above this callsite in the future.

Might that manifest in ways like this?

Screen Shot 2021-07-15 at 10.59.31 PM.png (816×1 px, 135 KB)

Fri, Jul 16, 3:02 AM
cspeckmim added a comment to D21686: Update "arc diff" to amend non-head commits with Mercurial.

Holy moly I'm not sure I would've found that out lol. My only guess is you've delved into the Mercurial source base (I've poked around a little)

Fri, Jul 16, 2:42 AM
cspeckmim added a comment to D21686: Update "arc diff" to amend non-head commits with Mercurial.

The desired behavior is that you can not enter any interesting workflow in arc diff if your working copy is dirty, so amendCommit() "should" be able to safely assume that any working-copy dirtiness has been made by arc, likely in arc lint, and is appropriate to amend into repository state.

Ah the stashing I'm thinking needs done is due to how (I think) amending a non-head changeset without evolve has to happen.

C
|
B
|
A* (changes from lint, want to amend)
|
master

Create a copy of A with the new commit message

C
|
B
|
A
|
A*  A'
|  /
o  master

Rebase B:: onto A'

    C'
    |
    B'
    |
A*  A'
|  /
o  master

And then strip A*

Fri, Jul 16, 1:12 AM

Thu, Jul 15

cspeckmim added a comment to D21686: Update "arc diff" to amend non-head commits with Mercurial.

Just for completeness for future readers: this behavior depends on history.immutable today, but arc would generally like to do this and Mercurial users broadly seem more open to treating local history as mutable today than they did in ~2011 (as does Mercurial itself, with changes like evolve).

Would this be good to comment on ArcanistMercurialAPI::amendCommit()?

Thu, Jul 15, 10:25 PM
cspeckmim planned changes to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Thu, Jul 15, 5:13 AM
cspeckmim updated the diff for D21686: Update "arc diff" to amend non-head commits with Mercurial.

Clean up the logic/nesting by returning early where possible. Add TODOs for work to be done still.

Thu, Jul 15, 5:00 AM
cspeckmim planned changes to D21686: Update "arc diff" to amend non-head commits with Mercurial.
Thu, Jul 15, 4:42 AM
cspeckmim requested review of D21686: Update "arc diff" to amend non-head commits with Mercurial.
Thu, Jul 15, 4:30 AM

Wed, Jul 14

cspeckmim added inline comments to D21682: Add a prompt to allow pruning merged branches when using --hold.
Wed, Jul 14, 4:19 AM
cspeckmim added a comment to D21682: Add a prompt to allow pruning merged branches when using --hold.

This is also shedding light on T13107 :)

Wed, Jul 14, 3:26 AM

Tue, Jul 13

cspeckmim added a comment to D21682: Add a prompt to allow pruning merged branches when using --hold.

In Git, we can just create new commits floating out in the middle of nowhere -- not on any branch, and not the ancestor of any labeled commit -- that you can retrieve if you know the hash but aren't otherwise reachable or visible to users without using very low-level commands. This isn't normally useful for human users, but it's great for reducing side effects in arc land, since we can do all our work in a sort of temporary scratch area that automatically gets cleaned up later.

Woah, yea I don't think there's anything like this in Mercurial. I take it these disparate trees have some limitations? Do they always apply to the working directory or something?

Tue, Jul 13, 3:45 AM

Mon, Jul 12

cspeckmim added a comment to D21682: Add a prompt to allow pruning merged branches when using --hold.

Just thinking aloud to myself

Off-hand I don't know of a solution that could provide that same guarantee for cherry-picking. Our current process also requires that the engineer who authored the fix is the one responsible for merging it, rather than having release engineers or an unlucky engineer responsible for performing all merges into the subsequent versions.

This could probably be handled by having the server-side hook check for commits with the same task number, as we require all commits to start with a task number. It's not as "comfortable" as ensuring the same changeset exists in the branch but since the changesets require merge commits which can potentially introduce incorrect merges that comfort might be just as misleading.

Mon, Jul 12, 2:18 PM
cspeckmim abandoned D21682: Add a prompt to allow pruning merged branches when using --hold.

The commits created as a side effect of arc land --hold aren't actually deleted explicitly, but they're effectively gone in Git as soon as you update your working copy to any other state. I'm not sure how closely this holds (or can hold) in Mercurial.

Ah yea this is one difference with Mercurial and Git's treatment of branches. In Mercurial there is no automatic cleanup, so things must be stripped/pruned manually before they will go away -- regardless of whether they're tagged with a bookmark or not. I'm still piecing together Git's handling of branches in my mind as I have used Mercurial for so long. Conceptually I know how I want to manipulate the repository but then things happen which reveal that how I'm thinking the repository is laid out isn't what Git's doing (Arcanist has been very useful in this respect).

Mon, Jul 12, 3:56 AM
cspeckmim closed D21680: An assortment of fixes and updates to using arc-land with mercurial.
Mon, Jul 12, 3:41 AM
cspeckmim committed rARCa43a3a9aabe2: An assortment of fixes and updates to using arc-land with mercurial (authored by cspeckmim).
An assortment of fixes and updates to using arc-land with mercurial
Mon, Jul 12, 3:41 AM
cspeckmim updated the diff for D21680: An assortment of fixes and updates to using arc-land with mercurial.

Remove TODO from ArcanistMercurialWorkingCopyRevisionHardpointQuery. Add some comments to functions in ArcanistLandEngine.

Mon, Jul 12, 12:12 AM
cspeckmim published D21682: Add a prompt to allow pruning merged branches when using --hold for review.

Oh just noticed your comment on this, marking for review so emails go out.

Mon, Jul 12, 12:03 AM

Sun, Jul 11

cspeckmim updated the diff for D21680: An assortment of fixes and updates to using arc-land with mercurial.

Made updates from comments. Re-ran the "Landing a non-tip revision" test and everything still looks good.

Sun, Jul 11, 9:24 PM
cspeckmim added a comment to D21680: An assortment of fixes and updates to using arc-land with mercurial.

I'll make these last few minor updates and do a quick few tests to make sure everything is still in working order

Sun, Jul 11, 8:58 PM