I think the remaining part was "show a lot more versions of different things", but I can't immediately think of cases where that would have helped us resolve something faster.

CORGI will fix this and clearly it is too hard for me.

That one worked OK, yell if you're still seeing an issue?

Test: User Guide: Prototype Applications

Oh -- I misunderstood. The issue isn't that we're getting invalid markup or emitting markup in a text context, but that the link is relative.

This is probably very easy to fix, let me spend 3 seconds on it.

Yes, Phurl provides URL shortening. U10 is the root object providing ((prototype)).

The technically-functional-prototype code is live on this install, now:

This isn't really the same as T7013 or T9161. T7013 was intended as a pure infrastructure optimization, I just named it really badly. And even if we had the fanciest rules imaginable, T9161 wouldn't help, because this case is currently unknowable.

Sorry, I picked a really bad name for it originally.

This task has nothing to do with any user-visible behavior and is purely a performance/network optimization, despite all the discussion about batching emails here. :)

You can use the default syntax (+x +y) to perform an AND search explicitly. See:

(There is also a different type of cache from <object hash -> metadata> we could build in Git, but that's kind of a lot of work.)

In SVN, we can use a different icon because we have prebuilt cache of file types (and must have this cache for other reasons, and can build this cache efficiently, and SVN distinguishes between binary and text files).

Please tell me if you would merge this improvement if we implement it.

Quick update:

One issue which we'll hit eventually is that git-lfs doesn't currently support pushing to remotes by URL, but we push to staging areas by URL:

Is there any chance that this feature will be implemented sometime soon?

No way for the upload API to say "no thanks, I already have that file"?

Why are users who shouldn't be changing priorities doing it?

See T10333 for plans to make dragging cards in sorted workboards more clear (and T8135 for additional discussion). Those UIs aren't as clear as they should be and we'd like them to be more clear.

"project" there just the noun, not "Project-object", but we could probably pick a different word to avoid ambiguity.

Quick progress update:

D15483 changes the constant to 47 (15 window size + 32 for gzip + zlib), which should accept and decode the broadest possible range of inputs. If this somehow breaks something, 31 (15 window size + 16 for gzip only) is probably the next thing to try. See that change for discussion.

This is probably a variant on T4551.

For searching across all types of everything, I lean toward adding an "Insert object reference..." button to the header which pops up a search box (similar to the "Edit Blocking Tasks" box) instead of trying to trigger on {T... and such. I think this is a lot friendlier for new users, and we'll have a bit more room to let you filter/customize the query, and this operation is probably not so common that it needs to be triggered on a whim inline. For power users, we could maybe add a keystroke (say, Ctrl/Alt + @) or something so you didn't need to actually click the button.

Here's a diff to make bin/storage adjust always run ANALYZE on every table after it makes other adjustments, but I'm not really sure if that's actually helpful or not (e.g., from the documentation, it sounds like the good analysis can be immediately overwritten by a bad one in some cases?):

I think so. Sorry for the originally misleading claim.Sorry for the originally misleading claim.

Oh, I might not have made subscribers actually do anything, I don't remember. They definitely should, though, even if they don't yet.

Well, the docs suggest not doing that:

Should we get rid of the <commitID, isDirect, changeType> key, then?

We could also maybe do something ridiculous like assume it's @2x if both dimensions are even, but M1461 has a 2X image with an odd height (1717px!) so that probably won't get us very far ignoring all the false positives for 400x300px images and such.

I think this is reasonable to build as:

Assuming this mode does not exist, the clearest pathway forward is for you or someone else to:

Does RuboCop actually have a mode where it emits errors and replacement text?

There is not, and never will be. Associated projects never affect policies, so there is no possibility to make them start affecting policies. I'm not sure what's unclear about this.

That one might be better to merge here, since it's probably impossible (at least, in the general case) but this talks about some things we can do in the general case.

By design, changing projects never affects policies. See the documentation here:

@jlvillapalos, can you shed some light on why you didn't include that information in the first place or how we could improve the process?

bin/remove destroy gives you a huge scary red skull-and-crossbones ASCII art for good reason, and you're accepting that issues like this may occur when you confirm the prompt.

T10599 asks for column move APIs, which are adjacent to this.

This transaction can only create a task into a column, it can't move a task. That's why the documentation says "Create into a workboard column.".

I don't think we can detect this automatically -- a, say, web-ready PNG from Photoshop generally won't have DPI information, as far as I know.

We are vanishingly unlikely to revisit this decision. If this is important to your organization, you should look into forking the codebase to provide the functionality you are interested in.

You can "Award Token".

We'll consider adding a setup issue if we see other users having issues with this. Previously, we haven't, so we presume users having or uncommenting these blocks in the wild to be very rare.

Interesting (and weird). Thanks for the update -- and good luck figuring things out.

I'm not immediately able to get --create to bring up a template with "Differential Revision". Here's what I tried:

I think we should ideally try to be more clear about the issue when the user passes --create, even if something in range says "Differential Revision: Whatever". That said "a little bit before I look at it" has been like two years now. Let me spend like 5 minutes on it and if it's a big mess we can just write it off.

The issue you're experiencing is because you're out of date.

In some cases, the effects of the theater can be mitigated issue-by-issue. For example, we may be able to write caching/rendering logic in Javascript to mitigate the performance impact on lightboxes and Pholio. We may be able to attach images directly to email. There may be a workaround for the Safari issue, or we may be able to do preview rendering partially in Javascript. With Quicksand, we can also increase the "hit rate" of client-side Javascript caches, at the cost of additional complexity.