How about this:

@avivey Implementation of T8092 is eagerly awaited, I am merely proposing a stop-gap solution of hiding the diff and base tags listed on the Diffusion UI for a repo when the same repo is being used as a staging area.
This would greatly reduce the UI clutter and allow teams to use tags as an effective version tracking solution.

(This isn't really very closely related to the Files application anymore, just cleaning up that board a little.)

I'm also slightly confused because, as someone just reminded me, the usual behavior of arc patch is to apply the patch to the appropriate base commit for the revision, not to try to do it on the current HEAD. In this context, that seems like it'd mean applying it directly to the arcpatch-A branch, rather than try to cherry-pick that commit up on top of where the user ran arc patch from.

Also T6482 seems like it's fixed. I've been quite appreciating how Arcanist is increasingly aware of dependencies between revisions.

Great! Let us know if you run into anything else.

thanks, this worked for me!

Yeah, the long-term plans are "automatic staging areas", which are essentially some kind of hidden refs (Probably using T8092 though, not just hiding stuff).

It was a little unclear in the walkthrough you gave on how to use it. Are the field types (animal.type plant.habitat) suppose to be hidden by default on when using a specific subtype (animal.type on plant subtype)?

Oh, of course. Good catch.

This feature was promoted in the week 12 release, see notes: https://secure.phabricator.com/w/changelog/2017.12/. Please remember to always upgrade Phabricator before filing a bug report, this task would not have needed to have been filed if you followed our guidelines on Contributing Bug Reports, specifically https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#common-fixes

I cherry-picked this to stable and will plan to push it to the cluster tomorrow morning.

We need to check programmatically whether all the reviewers approved. Any suggestion how this could be done?

This is also not a valid feature request.

Could you reopen and set it as feature request?

(This isn't related to the "Search" application, even though it's about searching for things.)

This does not describe a bug in Phabricator.

I implemented this recently but then pulled it out because ... project slug lookup is a gigantic mess right now.

@dreadlord2203 indeed, hiding those tags would be useful. I found one problem with using a separate repository for change handoff, and that is access control. If you maintain several repositories with different access controls, then you would have to duplicate each of them and maintain a second set of access controls for the corresponding staging repositories. This is a lot of extra work and it would be easy to make a mistake and leak the staging repo to people who shouldn't be able to see it.

I've gotten way behind this week so I'm going to cut and deploy the release now to try to catch up, then fix this afterwards and deploy it separately.

I can't reproduce this in production (8f7983a5be3a56db5b79dc7c3a0eb470f1d7ca02):

As a small step towards a more general solution I think it would be very helpful to allow the admins to easily revert changes, where revert means that there will be no traces left of the vandal action after the revert.

@avivey I am exploring that solution as well, I was just wondering if hiding the diff and base tags is a doable solution wanted by the community by large.
We have multiple hosted repositories inter-dependent on each other, and our setup is still in its nascent stage. So I would prefer to not manage duplicate repositories until we finalize on our long term setup.

thanks, I didn't think to use containerPHIDs, I'll give this a go this coming week and let you know if it works for me. Thanks!

Not everything you need here has modern API methods, but I think you can get pretty close:

D17604 adds the six edge types representing relationships between tasks, revisions, and commits to edge.search.

D17603 makes maniphest.search return a "description" field, which looks like this:

Some feedback on this for if it's ever prioritised and picked up again, we've been using this internally for an Unreal Engine 4 based game project's binary assets for about 7 months now, we haven't run into any issues. Works great for us.

If you can run bin/whatever, policies no longer matter since you can bin/storage shell or any other number of dangerous things.

Maybe let bin/search commands target a specific service.

PhabricatorEnv::beginScopedEnv(); works anywhere if this makes more sense as, like, bin/search self-test or something rather than a unit test.

It would be nice to build a practical test suite instead, where we put specific documents into the index and then search for them.