Some earlier discussion in T5781, although I didn't really have a clear way forward at the time and still don't.

There's also arc diff --browse but that does arc diff first, then browses the thing it just created/updated, so it's only useful in a much narrower set of conditions. We could possibly arc diff --browse --just-browse-do-not-diff but that's kind of silly.

You can arc branch, then arc browse Dxxx to do the lookup relatively quickly, but not as quickly as a hypothetical arc browse --the-revision-for HEAD.

I do think that if we were to assign a behavior to arc browse with no arguments, arc browse --the-revision-for HEAD is the most reasonable behavior.

It's probably reasonable to just add --revision (maybe with short flag -D?), hard-code it into arc browse, and make arc browse with no arguments mean arc browse --revision HEAD. No more-general use cases have really arisen since T5781 that I can recall.

My gut feeling is that our users will feel that arc browse --the-revision-for HEAD is too verbose for something that to them is a common and "should be simple" operation. However, if combined with the default behavior as you suggest, such that just arc browse defaults appropriately it would avoid that being a problem while keeping the meaning of the --the-revision-for HEAD option clear.

(As an aside not sure if you meant it literally, but I'd vote for arc browse --revision-for HEAD - removing the the.)

I'm not entirely clear on the distinction between --revision HEAD and --the-revision-for HEAD. If you just switched because --the-revision-for is too verbose, then +1 :)

Oh, the actual implementation would be --revision (with a short option), I was just using --the-revision-for for clarity (or extra confusion?) in discussing the meaning/behavior of the flag.

You'd actually type:

$ arc browse --revision <branch|commit> # Browse revision for head of <branch|commit>.
$ arc browse -D <branch|commit> # Short version, "-D" like "Dnnn"? But maybe this is silly and "-r" is easier to remember.
$ arc browse # Means `arc browse --revision HEAD` in Git.

Ah, sorry about that!

Sounds good.

On -D vs. -r:

Well, -r is more obvious if you already know of --revision. If you don't know anything, you're probably not going to guess -D nor -r. If you see -D in a command you might be more likely to be confused by the argument value not being a number, since you're used to seeing the Dnnn form. So perhaps -r is preferable? No strong opinion here.

I don't remember where, but at some point I explicitly asked that arc browse with no arguments will not browse anything, to allow [my] workflow of find-some-files | xargs arc browse. At the time, it was suggested that it would default to arc browse . (I think it only knew about paths at the time).

Do you type that explicitly, or would something like find-some-files | xargs arc browse --paths ("force any arguments to be interpreted as paths") be good enough?

Maybe --force could even just do that, without needing a new argument, since it already forces argument interpretation as paths? So the behavior would be:

$ arc browse --force
No paths provided.
$ arc browse
# Magic, tries to guess what you might mean.

I currently have b aliased to arc browse, so I type something like gfg TrainStation | x b.

I guess I can add --paths to b while I'm at it.

Maybe --force should be renamed to --paths then, because it's clearer?

Yeah, --force is a little weird as a name given what it actually does.

I'm also still not truly sold on arc browse doing magic. As an alternative, we could improve the default behavior to suggest both arc browse --revision HEAD (and explain what that does, if it would do something) and arc browse . (as we currently offer). I generally think there are a lot of tools available for users who want to optimize keystrokes (like shell aliases and arc alias) and it's questionable to privilege them over new users.

Stuff after T5055, etc., should also make it easier to distribute workflow and aliases and ship with arc b to really get those keystrokes down to a minimum.

Also, for future-me: arc browse XYZ (invalid object name) has an escaping problem.

After D16933, the behavior of arc browse <branch> on the experimental branch is:

• If the HEAD of branch is present in the remote (specifically: in Diffusion, in Phabricator), but not part of an open revision, browse the commit.
• If the HEAD of branch is part of an open revision, but not present in the remote, browse the revision.
• If the HEAD of branch is part of both, prompt the user to browse the revision or commit.
• You can use --types to limit the query to a subset of resolvers (for example, --types revision will never interpret the argument as a commit).
• If there is no argument, HEAD is tested according to the rules described above, provided the user is in a working copy.

So arc browse will usually browse a revision, and arc browse HEAD will usually browse a revision too, unless HEAD has already been pushed. Then you get a commit or a prompt, depending You can use arc alias with --types to create a browse command with different resolution rules.

There are likely still issues with resolution in general (see T11355) and various rough edges that will get cleaned up as I work through broader arc issues.

(If you name your branches ambiguous stuff like P123 you'll be prompted to choose between an object, commit, or branch interpretation and can use --types to narrow the query -- or just name your branches something unambiguous.)