I know it's an old thread, but I am encountering what is, as far as I can tell, exactly the same issue. I'm on the latest version of trunk (~Oct 26) with php 5.5.9 on Linux 3.13.0. I also observed the issue on the May 30 version.

Spaces have been working great for my install. The only real place where they're lacking I think arises from their coarseness/mutual-exclusivity.

That was sufficient to get what I needed, thanks so much.

Is there a way to find which object(s) an (unmapped) identity was discovered on? After a rebuild-identities, I have an empty string identity and a couple asdf-style garbage ones. I'd like to find the source of them and either fix them there or see the context to understand the appropriate identity mapping.

(there's usually no value in reviewing individual file-level changes in a "create a new branch X" commit)

Completely agree that there's no value in reviewing those individually. But to be clear, my point in making this ticket was mostly that you can't discern from the browser that this was a "create a new branch" commit. Right now it just renders the whole file tree saying showing 3000 files individually copied instead of a simpler/single line saying the whole directory was copied.

The new method of installing the shell completion seems to error out for me with EXCEPTION: (Error) Call to undefined method ArcanistShellCompleteWorkflow::getPrompt() on a fresh install:

For what it's worth, after spot-checking a few tasks on my install, all seem to query the same policy 10ish times in succession near the end of the load.

Not sure if it's expected in the current state, but here's one that doesn't seem well-formed: https://secure.phabricator.com/fact/chart/?y1=tasks.open-count.status

I'm unable to close this, but I believe this to be resolved (or at least my specific repro of flags via herald no longer applies I believe).

Obviously not a particularly important issue, but this now will populate a link in the favorites menu which leads to an exception:

Slightest of issues with the repository indexing mentioned above:

luca:~/phabricator$ ./bin/search index --type repository --force
Usage Exception: Type "repository" matches multiple indexable objects. Use a more specific string. Matching object types are: PhabricatorRepository, PhabricatorRepositoryCommit.
luca:~/phabricator$

I had indeed implemented precisely that herald rule once I realized that these diffs were being created without repository info attached. I also added repository.callsign to /etc/arcconfig to eliminate the problem going forward.

More or less ran into first issue with Q444.

I don't think this is quite the same issue, but seems related, so I thought I'd err on the side of not creating a dupe.

Voila.

(And again, to emphasize, I'm happy to drop this if y'all aren't interested. I have my solution and am happy ignoring this, but just thought it might be something you guys would want to check out.)

Head as of my Dec. 17 post in this thread. Can roll forward, but was hoping to wait till the edit engine migration settled a bit.

@epriestley any suggestions?

I did some further digging and made a little progress

Thanks for the advice. That yields the trace below. My understanding is that it was a diff with policy set to subscribers which had an author plus a single subscriber. That subscriber was added by herald upon the diff's creation, so there's certainly grounds for something going on there. I had trouble divining the exact issue, but tinkering with the permissions for the object ended up letting the emails go through.

Just updated to head and am seeing the same issues.

it's just likely very complex when we have to save an entire object state ... instead of approximately a single blob of text

Understood. For me personally, the single blob text would be more than sufficient. I don't mind repopulating everything else (assignment, subscribers, tags, customs, etc.) as those usually require much less thought and drafting.

No biggie, although the UI effect is obviously crucial for my org

FWIW, the answer to both of your questions before you edited it was yes :p

Thanks for such a quick response!

I'm not sure what to do with your link. Here's what I can reproduce:

Stock arcanist:

Well now I feel silly for not noticing that. I searched for the line number of the error ><

I suspect it's due to the replace status code. Specifically, if a specific path is removed + added, it shows as different than a modify. When this is then copied, it looks like SVN is showing this code for the new path of the file too. See /rSVNTEST8.

Doesn't seem specific to php.

Indeed. Sounds like I just need T5873 then. Thanks.

I would take great delight in using such a tool

Yeah, I think the end vision as in your mockup looks pretty nifty. Maybe part of the issue is that the photo thumbs feel kind of chunky in the workboard right now.

In T10308#158087, @chad wrote:

It's helpful if we understand the core issue you'd use names. That is, what are you looking for by seeing who is assigned?

FWIW, the second issue listed here is biting me too a bit on my install.

Oh, it sounded like the path forward was T3967, so I was unsure what people were complaining about given that things seemed fine to me, but that task was still open.

Confirming that removing the apostrophe from the slug in the db did resolve. Thanks.

I did indeed update across those 3 revisions you listed; I was previously at October 11.

I think I see the issue.

I too cannot recreate it.

Bummer. Thanks though.

Yeah. gotcha. At risk of suggestion solutions and vs. describing problems, certainly the way I think about it is:

1. What is the common prefix of all these file changes (i.e. /repo/projects/tfb/www/trunk/main/production/master/) aka where in the tree did I invoke arc diff?
2. What are the sub-paths w.r.t. the prefix of each file changed (i.e. path/to/file.c)?

Seems like that didn't quite get it yet (see D14301). Below is my transcript:

Ahh, looks like not. We'd been slowly phasing out .arcconfigs since the removal or arcanist projects.

Hmmm, I didn't actually move any files. Maybe this is a derivate of the issue in T9188 then?

On the other hand, there were observable effects in the similar case of T7284

You listed T7783 twice above btw. Was one of those instances supposed to be a different task?

I think this is T8800

I believe this occurred to me with Q120.

I'm gonna say this is moot now that arcanist project aren't a thing anymore.

Just to spitball...

Thanks for fixing things up there.

Ahh, interesting. Yes, I did.

You have succeeded where I failed ><

Some perspectives from what my users complain about to me w.r.t. mail: