What is the network speed of transferring a similar file (e.g., a 400MB file from /dev/urandom) via ssh cat <file>?

Per above, the decision to color the default state is explicit so this is likely just a design tradeoff in the short term. I can test things locally if you want to keep fishing.

There's probably no reason for us to have color: ... on the <select />

While checking again I noticed:

1. Explicitly setting the color: to #000 changes Last-Monday → Mid-April
2. Removing/unchecking the color: in the web inspector doesn't have any effect, it looks like because <select /> elements are inheriting that style in two ways. Removing/unchecking from both definitions/rules will change it Last-Monday → Mid-April

Is this the current status here?

I'm just going to merge this into T10448.

This almost certainly has nothing to do with being invited via a project. I'm just going to merge this into T10448, which will moot it.

I suspect this is actually more like: actions on Ponder answers are not covered by the "Ponder Questions" email preferences, because a "Ponder Answer" is not the same type of object as a "Ponder Question".

A possibly exceptional case here is users who unsubscribe themselves. We could wait for complaints or special case that.

This would be great. For example, in a Xcode project I could create packages for translators/localizers for any path containing *.lproj/

Seems better to pursue this as an CustomField extension. https://secure.phabricator.com/book/phabricator/article/custom_fields/

I think it should be possible to backfill this from the transaction record, but definitely a bit involved. Holding it until we do history (and major/minor versions) makes sense.

Per T12933, we never correctly implemented versioning, which is fix, but not backfilled. If we present a "history" view like Phriction, we'll need to do this.

Closing for now, it's reasonable to post populate the table if we do decide we need the information. I'll note it on T5505

No worries, and appreciate the help.

Fair enough; I'll stop bothering you now. D18280 looks good to me.

I don't know and I've spent way too much time here already.

In T12933#230136, @chad wrote:

I see no way of reconstructing the rows.

I see no way of reconstructing the rows. It appears versioning never worked (and nor do we surface it anywhere). We can add a migration to fix the current times though.

I may be mistaken, but it seems to me that D18280 will fix the problem only for new edits, made after that revision is applied. Is that right?

Seems a reasonable place to start. I'll look at this soon.

In T12933#230063, @epriestley wrote:

The creation date and modification date of a body should always be the same, like they are for a Phriction document body.

There's also bin/mail receive-test but that only accepts mail --to an existing object, not a random email address, right now. We could make that more flexible to make testing a little easier (raw_mail.txt must be a full piece of mail with proper headers and encoding, but bin/mail receive-test accepts just the plain text of a body and simulates all the headers/encoding/envelope stuff).

Something like:

I think I have a fix but can't find the command line trick you showed me to test it.

@hach-que, did you end up implementing a solution for this?

In case it helps: I think D13982 introduced the code being edited by D18253. But it sounds like some other code isn't behaving the way you were expecting it would.

I think you're innocent and that it never worked but I only looked at it for like 2 minutes.

I should be able to bisect this if I brokened it.

There may be a bug with the body versioning (maybe it got broken by accident when we swapped to ModularTransactions, or maybe it never worked), but if there is we should fix that bug. The creation date and modification date of a body should always be the same, like they are for a Phriction document body.

ok, that explains the Versions field - it appears only to increase when updating the Body and not the Preamble.

The create and modified dates are supposed to be identical, since each edit creates a new copy.

Maybe I'll put it on A, I guess ("Toggle All"), so it's sort of near q, which is similar (collapse/expand).

Toggle each individual comment's visibility to the opposite but only if it's not for the current diff~

If it's a toggle, what do you expect us to do if you press it with some inlines hidden and others visible?

Is there opportunity for a hotkey to hide/show all inline comments? Or since it's accessible from the topbar is the intent not to add hotkeys?

See PHI14 for priority.

And one more.

The easiest fix is probably to add a TYPE_CREATE transaction into ReplyHandler or MailReceiver alongside the other creation transactions.

This is now formally prioritized (see PHI14).

Only db001 and db002 are anywhere close to having problems with this and they still have a large amount of headroom, and we can bin/storage optimize at least some amount of additional headroom into existence, so this isn't "we're about to fall off a cliff" urgent or anything, but would be nice to tackle sooner than later.

We've had two customers hit this (both for Kotlin, although a config workaround is available).

It is, I planned on digging into it more. Tasks created via email don't get "created" feed stories. They say "renamed"

Is this a test or a bug report? If it's a bug report, how can I reproduce it?

Roger that. I don't expect support for it and it's quite minor, I merely thought it slipped through. I will let it be, and will use https://discourse.phabricator-community.org/c/bug in the future.

See Planning. We don't hide the real status in another tracker. If it's here, and open, it will be addressed. Please do not ping tasks.

@chad, bringing this up as it still persists after today's upgrade. Apologies in advance if replying to a bug is not the preferred way to resurface it.

I am also seeing this error and am trying to work on a fix.