This one's slightly trickier than T10570 because leading whitespace is semantic in lists.

Thanks for the feature request! This feature request doesn't have the information we need to move forward, so I'd like to start by trying to understand why it doesn't. Specifically, it does not describe the root problem you are facing, and instead asks for a specific feature.

Ah, you're right, thanks! I misread that page -- that does make Mercurial tags a lot easier to deal with.

Make it possible to add "subproject columns" in the parent's workboard

What version is libphutil at? This function was introduced in 821cad81.

Yeah, persistent details would be helpful. My best guess at repro steps from the screenshot is:

It needs a pile o' JS since it needs to change as you drag stuff around, but we can start with that.

I'm going to close this since there's no pathway forward that I can see. We might just not understand your request.

I slightly miss the card counts too, since we have points enabled on this install but don't really use them.

I'm going to write a CurtainExtension for it (I just missed it in the original round) but you might have to fix my bad stylin'.

I'll leave this open for now since the behavior still feels a bit spooky to me, let me know how things go once you get the key in place? If they're smooth, we can chalk this up to be being bad at MySQL.

I suppose the originally proposed key may be better than I think. I was imagining that it couldn't use the third part of the key (on changeType) but I suppose it actually can. I'm still confused by the UNION ALL behavior, but if the key's working on your dataset I think it's fine to add it -- it takes <1 second to add to our dataset, so even for large datasets it shouldn't be wildly unreasonable, even if we do find a better key later.

I'm seeing a replay of the (current?) rules about this message?

That's fine -- it looks like it's picking up the keys, I'm just not sure why it's then examining 303 million rows when it has the keys available.

Hrrm, let me see if I can reproduce anything like that, that's totally bizarre to me.

Hmm, weird. Can you show me the EXPLAIN SELECT ... for that?

Maybe we could add a "you weren't a recipient in the first place" reason which has priority over the other reasons, and make the text on the page more clear. Or just remove "Outbox" completely, I'm not sure it's really useful.

That is, "Delivery" is "delivery to you, the viewer". Maybe that's what's unclear?

The "Delivery" tab is specific to the viewer, not the mail. There's no way to see see why mail was or wasn't delivered to other users.

223663 is you adding a comment to Conpherence.
184911 is you moving a task on a workboard.
219192 is you attaching a task to a revision.

I can't actually see them, let me go pull up the console.

In all of them, I'm the actor, but they specify "Self Mail" as the (a) reason for voiding.
I do have "self mail" disabled, so it might be taking that?

D15459 is a partial fix here. Here's an "after":

D15458 is not a retroactive fix, but new comments made after that change should no longer be separable.

That key seems like it's probably not great for the OR changeType part of the query. If you still have the table handy and playing with it doesn't take an unreasonably huge amount of time, is this better?

getEnableCoverage() returns three values:

I'm going to figure out what the state of large PUTs

Sorry, I'm still not understanding what specific change you're concerned about. Isn't the information in the same place -- with the same behavior -- as it was before?

I miss the create date being easily visible.

I added you to Community so you should have access now.

To clarify, you're expecting the error message to disappear immediately, before you submit the form?

You can sort of do this like this:

This may make sense to at least lightly entangle with T4752, which overlaps in some ways.

To do an integrity check, it looks like we have to compute the Git hash ourselves.

As a general preface, this stuff makes me a little uneasy about LFS in its current state:

D15454 changes the wording to:

We should probably change the text on "placed up for grabs" to "unassigned from X". I don't think we use that term anywhere else nowadays, either.

The "Issue Events API" appears to provide the remaining events in a different format with different rules. It does not provide any duplicate events, so, e.g., one API retrieves issues being created and commented on while a different API retrieves labels, milestones, etc., except that both report opens and closes, I think. Anyway, seems mostly workable.

Alright, so here's the first real issue. Here's what I did on GitHub:

is there a way to add subscribers via lint rules?

Primarily, I'm just hesitant to make changes where you upgrade and previously-private stuff becomes public, since I think that's a terrifying behavior in the general case and maybe even worse than destroying data.

To provide a little context, I suspect we'll just make personal rules publicly visible. Long ago, transaction records were not as explicit or complete as they are today and you could sort of hide your "keep an eye on the suspicious interns" rules a little better, so this policy behavior wasn't totally silly, but it's almost impossible to actually hide any information now.