You can already execute this as:

`echo {} | arc call-conduit user.whoami`

Is there a reason to expose this as a first-class command? I haven't encountered much need for it...

@epriestley,

I agree that you can do it over conduit, and it's quite straight-forward. But here are some use cases:

1. Someone might plan on having an admin login and a user login for my phabricator instance with lesser privileges. They might want to check who they're authorized as.
2. Someone might opt to write a shell script to do something (say write an audit log on a shared NFS). So they can do something like:

$ echo "New action by ".`arc whoami` >> /shared/log.txt # of course, this won't work with current output scheme

I just feel that any RPC system should allow the user to know who they're authenticating as. To back up my suggestion, here are a couple of references:

• NPM has a whoami command
• Heroku has a whoami command

If you feel this isn't important, then I have no issue with it. I know quite well how to use conduit to solve this problem for my own needs if they arise.

Broadly, even though a feature might sometimes be useful, every feature imposes costs: e.g., new users have a slightly larger set of arc commands to look over, and we have to maintain the code. While this feature isn't literally useless, I think it would be the least useful arc command if we added it, and I would expect it to cost more in its lifetime than the value it provides.

In particular, no one has ever asked for this and I can't recall any situation where I wanted it or wished it existed when helping users. I'm not aware of any users who run multiple identities (generally, I think this is hard to do now, but no one has asked for better support). In the logging case, whoami is probably more relevant than arc whoami, and doesn't require a server roundtrip. And we already log Conduit calls on the server side.

Since dropping this into arcanist/src/extensions/ should be sufficient to activate it, maybe we should look at some kind of formal contrib/extensions stuff? In the long run I think we want to build a substantial amount of infrastructure for third-party applications, but maybe it's worth setting up some intermediate step now.

@hach-que had a "phork" he was maintaining but it looks like that might have been dropped.

Yup, I stopped trying to maintain that, for two reasons:

• The patch lists were a nightmare to automatically rebase; if upstream introduced even a single line that's incompatible it'd break the whole patch list until someone (e.g. me) manually intervened, which could even require rewriting depending on upstream's changes.
• @epriestley turned out to be right in all of the cases where he said "this is a bad idea and I don't want it in upstream". So when @epriestley advises against something or says that a patch sounds pretty useless, that's because it probably is. It might have something to do with @epriestley working on this codebase since 2008 and about 5 years longer than any of the contributors like me, but I can't be sure... ;)

hahaha :P