When I add the dependency in the webui, I *do* get the diff-display behavior I want.

Sorry to complicate: My original assumption is that if I

For additional context, the reason we use arc diff <other commit> in our workflow is because we've configured git.default-relative-commit to be origin/develop. We're discussing removing this so that we 1) use the default behavior again and 2) encourage people to use arc feature so that branch tracking is set up in such a way that arc diff works as expected.

I use the same workflow. Manually running arc diff ${ other diff's commit } is a bit painful, looking up the other diff's HEAD commit and being super careful to pick the right SHA.

I believe there are cases where it is advantageous to have one revision with "A" and one revision with "A+B". I'm not sure what everyone calls it, but I've heard it being called the "git rebase workflow" before (versus the git merge workflow).

Something representing a prison, quarantine, or really good fence? I'm also a fan of the spooky ghost.

In T11284#184462, @chad wrote:

Can you give an example of what specifically you are trying to build in Phabricator?

@epriestley, just thought you'd like to know that, on that aforementioned massive task, the task names are now entirely missing. If you scroll all the way to the right, it shows the assigned person, and that's it. :\

Thanks for the analysis and the change. It makes a lot of sense to me now and, to be fair, I wouldn't have even seen the exception had the repository finished importing, which is what the fix does.
Thanks again.

Ahh, yeah D16234 was it. I'll make sure to update to HEAD next time. Thanks guys.

shruggy_ghost

haha i was just thinking the same thing with the spooky haunted file task.

Some kind of ghost would be good too, but not too snapchat-ey.

All files from before you upgrade to D16270 are haunted and subject to ghastly behavior.

D16271 probably either fixes or moots this.

I can't really reproduce this, exactly, I think (?), but I suspect I can fix this and T8124 by just making this code simpler.

Please update Phabricator and re-test. We require bug reports be made at HEAD.

(This doesn't do anything bad, just spams the logs a bit, so no rush to update.)

Update past D16234 (July 5).

In T11307#185338, @epriestley wrote:

T10907 is also sort of adjacent.

I just wanted to add a vote of support for this (following up from here) - for Haskell.org Windows is one of the "Tier-1" platforms that we ship binaries for, and having continuous integration is exceedingly useful for a number of reasons.

T10907 is also sort of adjacent.

When moving a repository from "importing" to "imported", we check if any commits are marked as still needing to import.

The above analysis is correct.

Just encountered the same problem :(

Can you update this ticket after reading this wiki please. It will save time for both you and the upstream.

Since it was super late and I should go to bed i decided i should try and figure out what it means.

You must include reproduction steps when filing bug reports. See Contributing Bug Reports.

Specifically, we're happy to take feature requests that state a core problem a user is having using Phabricator. I don't see any core problem in this request and I can't really come up with any problems integrating Facebook at Work solves that installs can't resolve in other ways. I can't even really understand what "integrate them" means, exactly. Just authentication? I don't see where they offer anything else and in order for us to dedicate time to something, we need to expect a portion of our installs to adopt that feature.

See Contributing Feature Requests for how to file a feature request.

Oh wow! Thanks for looking at this on a Sunday morning!
If this is expected then I think there are a couple of things that are happening that could make it better:

1. It looks like an uncaught exception, which seems like a crash and definitely says "unexpected"
2. It gives no explanation of what's really going on here. All there is is Commit "191140" has been deleted: it is no longer reachable from any ref., but it's unclear what 191140 is, and it doesn't look like a valid commit, so at a glance, it looks like something isn't getting parsed right. It is also happening while parsing a commit that I can't find in my local copy, but it exists in Phabricator's local copy. An explanation on how that could happen would be useful, too.
3. Most importantly, it gives no way to get out of this state. There are now commits stuck in "Importing" state permanently, which leaves the entire repository in an unfinished state. Providing the user with a facility to resolve this (and pointing them to it in the error message) would go a long way here, even if it's something simple and brute force, like ignoring this commit, or marking the whole repository as imported (which is what I ended up doing).

I deployed that stuff to the affected shard and things look OK now. The original issue described in this task wasn't affected.

You can still create limitless rooms with titles with 1 other participant. I just want a means of messaging one person in a persistent place without a room title. It's definitely a bit cumbersome to just send 1 person a quick note.

(We don't need to require a room name, and I think that's only a skin-deep UI requirement and not actually enforced lower down in the code.)

This didn't really end up being related to the other issue here (streaming huge diffs into Files) but it's a little late for me to split it out now.

parsing probably shouldn't crash

This is largely the result of --find-copies-harder being explosively slow for large result sets in large repositories. With this flag, the runtime rises from <1s to >3m, at which point git itself bails out:

This is actually happening on the cluster/daemon pathway so it's not really related to the original issue here. However, the daemon client is timing out:

I suspended the instance in question since it was a test instance, and continuing to generate web requests for the 5M-line diff and disrupt other processes on the shard.

We had a shard disruption in the cluster this morning that I don't have a clear smoking gun on, but one issue that looks questionable is on this pathway -- I see several requests to generate diffs of an extremely large (5M line) commit coming from the web.

I'm with @epriestley on this - on our install I too have multiple discussions with same individuals, discussing different topics :) It keeps things clear.

At least personally, I don't think this is weird -- I think of it like sending email.

Yeah, T8124 is definitely the error user-facing I saw when this occurred, except there's no possible way to edit your profile pic at that point as the exception takes up the whole page.

I think it would be better not to fallback at all and raise a setup warning. We'll likely have other issues in the future for not using the native driver.

T8124 is probably adjacent.

What I found interesting about this bug is, I've had some obvious high latency with this storage engine - but incremental storage uploads for large files work fantastic in every use case I've tried, e.g. cancelling requests and all kinds of stuff. I guess this 'magical' default profile picture creation can't use the 'resume upload' mechanics?

(I made about six typos in the original version of that comment, so reload if you're following the steps from email.)

It's possible that we're in the wrong by falling back to set character set utf8;.