This is currently difficult to do because it involves bulk editing our entire workboard

We run this entire algorithm ourselves and it's pretty simple (basically just looks at indent levels, no language awareness). Should be pretty easy to have it peek at the previous line if it initially finds a line containing only "{" and see if that line is at the same indent level and otherwise suitable.

(We could theoretically fiddle with this and include some time constraints and stuff but I suspect this rule is already the best rule we're really going to get, given how contentious/subjective the subject is and how little complaining we hear about it, relatively.)

We don't show a specific amount of history: we show all activity since your last activity.

D14452 and similar seem nearly certain to obsolete this.

See Contributing Bug Reports.

We now have execute as well.

We might build this as a side effect, but there's been no actual interest in it.

We now have better behavior in general, and no other reports of this in a couple years. The underlying use case also isn't clear to me; build artifacts should be .gitignored.

They now sort by date and have some options.

This was directly obsoleted by the removal of arcanist projects.

The future of these pipelines in the upstream is server-side, not client-side. See T9530.

This hasn't really surfaced to the upstream in the last couple years.

Haven't seen more issues here in several years.

This is now meaningfully achievable through Drydock as a repository operation, but we've seen very little interest in it.

We'll continue down this path, but I don't think there's much value in keeping this task around -- more modern tasks like T5447 cover the same ground more usefully.

We haven't seen further interest in this in several years.

No upstream use case in years.

See T1562 / T4171 for modern versions of this.

The use case I'm trying to cover is to create notifications for open tasks that are past their Due Date (custom date field that we use).

Presuming no one cares anymore.

Given the modern realities of support, I don't actually think we'd be better off by making it easier to submit stack traces. We also explicitly don't want surprise patches.

Pretty sure this is just a bug, auth and conduit auth have each gone through a major rewrite since the last time the log was touched.

Yes, see Paid Prioritization. Shoot us an email at contact@phacility.com if you'd like to move forward.

I conceptually like the approach you outline for --only-new.

Sniped!

Please see:

Yeah, I'm onboard with that plan.

(This is just a note for me to make sure I don't forget about it, I'll follow up here before we unprototype.)

Are you planning a fully specifiable merge command so we can run anything we want for merging?

running arc diff --update with an accidentally incorrect revision ID would be less likely to succeed if revisions were only editable by their author

I suspect T9132 will address this use case.

This was fixed as part of T9657:

accidentally updating revisions that aren't theirs

What's the actual error you've encountered when trying to add such a file?

https://secure.phabricator.com/book/phabricator/article/prototypes/

https://secure.phabricator.com/book/phabricator/article/prototypes/

• I cherry-picked this to stable (rP111c48b2).
• I deployed this fix to the Phacility cluster.

I don't think there's any way we can reasonably run pre-receive hooks from the test console in the general case. The pre-receive pipeline reads state directly from the underlying VCS, and much of that state is transient (e.g., we may read svn look --transaction <txnid> or whatever). If a user gives us a push log PHID to test later, we can't really rebuild most of the state.

I'm fine with giving this a shot.

Wasn't aware of this one, thanks.

See Planning (briefly: we don't know).

See also:

This is already prioritized, yes. See the weekly dev log for my plans through the end of the yar.