My inclination is to push to v3+ or go the bots posting to a read-only chat room route.

I kind of wonder if this got fixed by accident since it's been glitchy for me forever but seems fine at HEAD in my recent threads. Maybe just none have enough big images, though.

I don't think this is worth fixing in general. It doesn't do anything bad (just dump a warning to a developer log which users normally don't see) and fixing it isn't trivial.

Cool. D12756 should resolve this in the general case by terminating loops as soon as we try to re-load an object we're already loading.

Yep, should be safe (although the first two rows are probably the issue?).

T8119 hit this in a non-theoretical way.

(This is the only thing I've been able to break so far, the other stuff that I was able to repro earlier seems good now.)

I like that "phundle" is uncomfortably close to "fondle", too. Win-win!

pls help

I think this is reasonable to keep open separately since it's almost certainly the first use case, but I think T5055 is probably most of the groundwork ("build a general package management system to support Phabricator applications and Arcanist extensions").

This is probably related to (and maybe the same as) T5055.

I don't think we have enough to go on here to try to build some syslog wizard yet, but maybe after we collect more problems.

Here's a more concrete description of the problem. Overall, there are several use cases for these controls:

After rCOREbfd9c20f, we automatically rotate daemon logs when restarting them and compress old logs.

Somewhat related is that visiting a project with a workboard will take you there, but notifications like "X edited project visibility" should probably take you to detail unconditionally? Maybe? Or the workboard should also clear these notifications, at least.

@joshuaspence: does disabling the xdebug extension resolve this?
@rymndhng: do you have xdebug enabled?

Our plan is to build a real reporting application ("Facts", T1562) and remove the cobbled-together reports UI. Cursor-based fact extraction doesn't depend on these indices. T4434 covers closed objects, although this will probably be extracted separately as well.

We don't plan to support this. There are various technical/product/priority reasons, but philosophically I think it's important that ownership be unambiguous. I'm also not aware of any task systems which support this.

T8011 is at least superficially the same as this, and probably the same at the root.

This moved into an email thread so I'm going to close this out, but let us know if we can help with anything else.

Closing for lack of feedback; this request doesn't describe a problem.

Maybe "duration mode" should be a dropdown, and we should parse durations out of "text" mode.

A third possible mode, which only makes sense on some controls, would be a "duration" mode. So you'd have:

...fixes the immediate issue, but then we hit something deeper down:

Thanks for the report!

Thanks for the report!

I think we're just coming at this from very different use cases. If a diff has this line:

Just to double check, you definitely don't want the example in T7447#112231 (where only one character was changed, directly addressing an inline) to port forward in an ideal implementation?

If you make a change after the comment, it still ports forward, but any change in the hunk prior to the comment seems sufficient to stop it.

Here, I directly addressed an inline by making a one-character change:

Here, I changed line 7:

Ah, I got some of them to port forward.

Given your experience with GitHub Enterprise, would you expect the comments on the pull requests I linked above to be porting across updates if GitHub had behavior equivalent to GHE?

Chad's comment on the diff view didn't port into the file, and didn't port forward when I updated the diff.

None of the comments are visible on this view, either:

Can someone show me how to use this feature on GitHub? For example, my comment here: