I don't think we should change this.

We'll accept this as a bug report if you describe the conditions which lead to a newline after "Summary:". The expected behavior is that there is no newline.

Oh, sorry, apparently @chad got this right then and I misunderstood.

Ah. From the workaround ("View Unified", then "View Side-by-Side") I'm guessing the menu maybe isn't refreshing properly somehow, but I'm not sure how to reproduce it given the provided steps.

I can't immediately reproduce this -- were you able to, @chad?

I merged T11740 and T11739 here since they're approximately the same problem from our perspective ("make messages adhere to project rules, where the project rules are immutable").

We use a heuristic to guess which function, class, etc., the context is in. Git uses some similar heuristic.

The code is a little better factored now and it's possible that the patch to DifferentialInlineCommentMailView is a pretty small one (and it may work in both text and HTML modes, as a possible benefit, although I suspect your install's use of HTML mail is much lower than most).

@klimek Your install is the only install we're aware of that is interested in a rendering mode like that (feedback about the old rendering was generally negative; feedback about the new rendering has been generally positive). Unless we become aware of much wider interest in such a rendering mode, I don't plan to reintroduce it upstream.

@HarryOtto, your message is off topic in this thread and is so tenuously related to anything here that it looks like it might be SEO linkbuilding spam, so I've removed it.

Design atrocity incoming for T10747.

I think there is an extremely rare policy error somewhere in the policy code that we've occasionally seen in the form of sporadic unit test failures. I haven't been able to reproduce them in the same environment and they're false negatives (e.g., prevent access when it would be OK to allow access) so I haven't spent a ton of effort hunting them down, but it's possible that they have the same cause.

Rough overall state of the world is that "all the hard stuff" is mostly "done" but it's probably fairly buggy, so I'm going to push on exports and some UI stuff for a bit and try to catch all those bugs while I do. Also imports are probably hard but I'm going to imagine that they aren't for now.

Yeah, agreed.

I think I'm going to move the recurrence controls to a separate screen, so you'll make a recurring event in two parts:

I think it sort-of does something if you upload an irregularly-sized image (say, 100x200) instead of a square image. But I don't think it's particularly useful or works well even in that case, and I definitely support getting rid of it.

Should basically just be UI, yeah.

Looks like we use the function to mean "codepoints" in some places in phabricator/.

With no claim that this is the world's most elegant fix, I think this may be a fix:

In the short term, I'll accept a patch to do this if you want to test it?

T9640 and T2383 are somewhat related.

When you upload a file that is stored as chunks, the chunks are also files. For example, file F123 may have chunks F124, F125, F126, etc. These files are not normally visible in the web UI but you can see that the next file you upload will skip some numbers (e.g., be F127).

Why do you believe that files which are split into chunks don't get encrypted?

The examples that use the BYSETPOS and WKST rules are omitted, because these rules are not supported by Oracle Application Server Containers for J2EE.

I'm sorry you feel that way. These kinds of requests are frustrating for us too, which is why we try to make it clear upfront in the documentation that this is not an appropriate forum for them.

Since it doesn't seem like the documentation is incorrect anywhere, this doesn't appear to describe a bug in Phabricator which we can accept upstream. See Support Resources and Contributing Bug Reports for details on what we do and do not provide support for.

Please file a new task following Contributing Feature Requests if you'd like us to consider your feature request. We do not track resolved tickets.

Please see Contributing Feature Requests and Describing Root Problems for guidance on filing a valid feature request. You need to follow all the instructions in those documents before we can accept your request upstream.

Additionally, coming to phabricator, my expectation is that arcanist would handle the front-end (i.e. phabricator), but not strong-arming my local development environment.

That document says:

What led you to arc land, specifically?

Also possible is stuff like "the diff has a custom policy which you destroyed", etc.

If an object exists but is failing to load, it's usually because a required related object does not exist (in most cases, "required" means "required in order to evaluate policy checks").

This isn't a bug -- I think we've just set you up with the wrong expectations somehow. There's probably some sort of documentation we can improve to make it more clear what arc land does, and maybe I can figure out how where we led you astray by asking some questions:

Yeah, ON DUPLICATE KEY UPDATE is sensitive to order. Setup:

I think this is:

(The major goal of using refs instead of tags wouldn't really be to hide them per se, just to make them extremely difficult to fetch by accident.)

Maybe my assumptions about default behaviors are off, or the more-recent base tags (but not necessarily the diff tags) are getting fetched because they're often ancestors of master?

I'm a little confused about how these tags are appearing so widely in developer working copies in the first place. Is git clone fetching them by default? Do you have unusual default options configured? Do users regularly explicitly fetch all tags present in the remote?

I think cleaning up closed tags probably isn't a particularly great long-term solution since some fraction of the revisions likely just get left open forever -- so you'd have 500 tags instead of 50000, but I assume that still causes about as many problems, and you'll be back to 50000 in just 100 more years anyway.

See some discussion in T7944, particularly T7944#194982.

We're planning to put application-level stemming on the MySQL index (see T6740). Are there problems with the InnoDB search that you're aware of that aren't fixable with application adjustments?