Page MenuHomePhabricator

Create an `arc status` workflow
Closed, WontfixPublic


I think that it would be useful to have an ArcanistStatusWorkflow class which provides an arc status command. This command would show information about the current differential.

Example output

**NEEDS REVISION**  D1234: Create an `arc status` workflow.
Commit message here. 

@epriestley requested revision.

**Lint:** OKAY
**Unit:** OKAY

Event Timeline

joshuaspence raised the priority of this task from to Wishlist.
joshuaspence updated the task description. (Show Details)
joshuaspence added a project: Arcanist.
joshuaspence added a subscriber: joshuaspence.
joshuaspence renamed this task from Create an `arc status` workflow. to Create an `arc status` workflow.Jul 10 2014, 8:57 PM
joshuaspence updated the task description. (Show Details)
eadler added a project: Restricted Project.Jun 17 2016, 7:04 AM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jun 17 2016, 7:09 AM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 4 2016, 9:05 PM

To summarize discussion from elsewhere: it isn't clear to me when this is better than other tools -- including arc browse D123, which already exists.

One use case that was floated elsewhere was "follow up with reviewers about the status of a change", but you can already use arc list or arc branch to see that changes need review, and arc browse to open the page for the revision (and arc browse will get easier after T10895).

If you want to check which reviewers you need to follow up with and then follow up with them, you presumably need to open the browser to do step (2) anyway most of the time (e.g., leave a comment on the revision like "Hey, review this thx"). Reviewer status is prominent on the page at the top, so I think the workflow today is something like this:

  1. Optionally, use arc list / arc branch to check revision state and get the revision number. You can skip this more easily after T10895.
  2. Use arc browse to open the revision (via number today, or branch name after T10895).
  3. Write a comment on the revision pinging reviewers.

It seems like arc status just adds an additional, redundant step between (1) and (2) on this workflow.

Even if you strongly prefer working on the CLI to working in the browser, it doesn't seem like this lets you shift the workflow to the CLI.

I'd like a better sense of use cases for this before building it, since without use cases I worry we're just building arc chrome-browser-cli-emulator <uri> and we might be better off supporting the CLI browser UAs like links explicitly.

T5088 is a possible use case (report if the current revision needs an update), although I feel like it's a bit flimsy.

epriestley claimed this task.

I think this has failed to collect any compelling use cases in several years and don't plan to pursue it.

Today, experimental and wilds can open the current revision corresponding to the working copy state when "arc browse" is run.