@avivey I understand the concern here with how complex that <thing> can actually be but I feel that arcanist is dropping information that is useful. I would go as far as to say that Phabricator should store the plain <thing> that the author used (the intent of the author), and the more complex version of <thing> that Phabricator might actually care about like in T3462. Overtime it may impossible to go from one to the other. Ex. If you Phabricator were to store <thing> as a commit hash, and <thing> was originally a reference to a branch HEAD, looking back you may not be able to figure out which branch was originally meant by the commit hash since that commit can appear in multiple branches later on. This feels important to me seeing as how branches are the main way of organizing repositories by users (along with tags etc) and may represent something important in a project (like when building). Sorry for the rant haha.

This would be really helpful when reviewing code (having context about where its going especially which multiple release branch scenario). It would also be really helpful when building revisions in a build system like Jenkins where different branches need to be built differently (different SDK's etc) and getting from revision to what branch its going into is non trivial at the moment.

@epriestley I think this a quick and reasonable ask to incorporate into Arcanist and Phabricator. Do you agree/ see any potential issues?

On a side note, does anyone know of a way to clear (PhabricatorApplicationTransactionPublishWorker) tasks from the daemon queue? These will fail forever on my system since this user does not have access. Multiple have already failed over 6000 times to send the email.

@epriestley Did a little more digging in phabricator and it seems to be trying to email an employee who has a herald rule that emails him on any commit anywhere (he doesn't have access to all repositories though).

In T9067#130507, @epriestley wrote:

Are people supposed to be able to see the repo if they are not in the project but in the space?

Yes. Adding projects never affect access control.

@epriestley I believe this is happening because I have the repo in a space, but it also has a project set on it. I noticed that if you are in the space you can see the repo even if you are not in the project? I believe the person it is trying to email is not in the project but is in the space. Is this intentional? Are people supposed to be able to see the repo if they are not in the project but in the space?

But what if the people you are trying to mention are not part of the project. But may need to be aware of a change coming in to API etc. Also, people may not wish to be watching projects in order to not get tons of email about all things going on in the project. Hence the mailing list request.

You could use the same symbol as users? It makes logical sense since a mailing list is just a group of people. Another way to implement this feature would be to allow the creation of user groups (teams) that can then be referenced the same way users are in comments.

Any progress for this? It is currently holding up the import of some of our svn and git repositories (stuck at 99% done due to consistent commit message parse failures due to emoji).