Alright, that's promising at least. Thanks for testing!

We could also possibly just drop these commit mails in all cases where no audit triggered. It's easy to write a Herald rule to restore them if you do want them. Possibly involved enough to be adjacent to T10978, though.

A small part of the motivation for this change was to make commits reachable only from Gerrit magic refs (refs/changes/..., similar to refs/pull/...) visible in Diffusion. This didn't really make it into a single upstream task I think, but some of this is scattered across T9726 / T6878. So we have at least one use case where users want these refs to exist and be treated roughly like they were tags/branches.

I do think there is significant room to improve the behavior of arc diff (roughly captured in T6072) but I'm ultimately not sure how to improve this situation:

Yes, writing "Depends On" in a commit message or editing "Edit Parent Revisions" or "Edit Child Revisions" in the web UI should never affect what is shown in Differential. If you can reproduce this, this is a bug which we'll fix.

Please see Planning for information on timelines.

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.

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

Update past D16234 (July 5).

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.

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

(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.

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

T8124 is probably adjacent.

(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;.

That option is "comment out the check", as @khanhicetea has done in T9640#184512. Phabricator is open source, and you are free to modify it.

I believe there's no actual issue here outside of the RSVP/instancing issue and other issues resolved or tracked elsewhere. If there is, file a new report -- with reproduction steps -- after Calendar leaves prototype.

(Only unique queries are saved, so this should be a small amount of data in most cases, but the Phacility setup tends to mean we issue a lot of unique queries.)

Using an extended policy sort of fixes this, except that extended policies currently only strengthen policies, so I also have to weaken the default View policy. This potentially makes the UI misleading, since it suggests that "all users" can view an instance, which isn't true.

One possible approach is to cache policy checks (when we've determined that user X can see object Y, cache that for the remainder of the request), but I don't want to do this idly since it has far-reaching implications, and there are cases where this cache could potentially produce the wrong result (for example, when we predict the effects of making a policy change during an edit, we evaluate objects as though they had a different policy than they really have).

Everyone got to learn something new about Git today!

Whatever string this is:

(The harbormaster_object table is just a test table used by unit tests.)

You could also try running these commands against MySQL:

You can likely reproduce the issue in a repeatable way with this command:

Seems like that commit imported fine.

Sounds like this is resolved for now. Feel free to file a followup report if you are able to identify reproduction steps.

I can't reproduce this. Bug reports MUST have reproduction steps.

That's not expected and I can't reproduce it.

I'm going to merge this into T10252, which may not be the same issue, but which has reproduction steps.

D16259 should fix the autocompleter on German layouts.

T11263 may be related here.

(My guess is that 95% of the time the engine can just match all ".js" or ".php" or ".c" or ".m/.mm/.swift" files and get the right result without requiring configuration.)

My inclination is to implement something like this:

This is reasonable, but should wait for T5568, which probably needs T5055.

Presuming resolved based on followup issues and stargazing.

Presuming this was resolved by D16095 since we haven't seen further reports, or new reports of brokenness.