What does git show show in arcanist/?

Oh! So it already has this feature! I wonder if perhaps we are on an old version. I tried arc version as specified here, but I just get an error:

I think we're too conservative about invalidating this cache. To reproduce:

The warning seems to be working properly for me locally, so I can't reproduce the issue if the claim is that it doesn't work:

Oh I was thrown off by the quotes and not a var.

I think it's right:

That pht seems to have too many %s ?

The expectation is that you should get this prompt when trying to arc commit a change you did not author:

It's very common to land other people's diffs (who do not have access to the repository) and comandeering changes the commit author.

One broad issue is that admin.phacility.com sees a generally high, sustained request rate of almanac.service.search calls (up to dozens per second). I think the uneven performance I've sometimes observed is just load-related, and that this load is sometimes high enough to max out the Apache workers and cause queue stalls.

👍 testing it now.

This is probably the fix, if you want to test it and diff it before I do:

See also vaguely related T12505.

Basically, I think we already have mostly reasonable behavior here (we do all the easy stuff correctly already).

We could retain a separate "@catlover74 is now named @doglover74" record, but I believe it would mostly only be useful in this case, although there is some overlap with T4267 and T1731 (now merged into T12164).

I would argue "rename" isn't really "rename" if all linked references don't get updated BUT I also would be super-opposed to things like git history/commits being re-written (and there may be other cases I don't know of that I would be pro/con to). At some point you'd want to draw the line and I, personally, don't have a solid use case for moving the line.

(We could silently rewrite @catlover74 in comments to be stored internally as {mention PHID-USER-asdlnasdlbn}, which would at least partially retain integrity for comments. However, I don't think there's much we can do about commit messages. We currently don't perform this class of invisible rewrite for any other rules -- the remarkup you edit is exactly the remarkup we store. This isn't out of the question, but I'd like a stronger set of motivating use cases for it since I think it's potentially fairly involved.)

I believe I understand now, however then I have one inquiry. Would there be a way to keep some sort of reference between the old username and new one, so if someone clicked/hovered on that mention the lookup would have some context for a rename that occured in the past. Would have to keep a chain then because people might rename more than once.

I did a local test of a rename and the fact that things like what I mention ^ would be a problem are the reason I'm not renaming current (not new) users.

Correct, I may not be 100% on this but I believe they are using a regex (sorry to trivialize if this is true/untrue/complex/etc.) to do some of the linking for things like me saying @enckse here...not to mention commit messages and the like.

I didn't anticipate that, conpherence entries would be.... a lot of stuff to slog through.

Integrity is broken only in case where something literally uses the old username ("the old username ... anything which uses it").

I think the (potential) opposition is that they'd have to process all the remarkup as well

I've interpreted the text as renaming a user will break references to objects the user has authored/interacted with. As in, a single transaction occurs and user who is named A is now named B, however all objects that were authored/interacted with will still have a reference to user A, which now no longer exists.

See also somewhat-similar T12592 and T8918.

Can you describe the behavior you expect, given the text of the message? I think this is an issue with the text being unclear, but I'm not sure how you've interpreted it.

Oh hai I'm still busy busy

Behavior above sound right? I'll shoot you a diff...

not intentional

Actually, I misread D17678, which just replaced the grey dot with a violet dot in all cases.

That seems to decide that "\n\n" is "trailing whitespace", which doesn't really make sense to me, but [ \t] might work better than \s.

The expected behavior is that environmental variables are passed to subprocesses -- except in the case of T12071. This is true in the general case. If it is not true here, and not a configuration issue particular to your environment, we must have some uniquely incorrect behavior affecting LD_LIBRARY_PATH specifically, so I'm reclassifying this as a bug.

We can look at this in more detail eventually, but I think there's like a 99% chance it's configuration issue which only affects you, not a bug in Phabricator, so it may be a very, very long time before we pursue it.

Per above, I'm pretty confident this is on your end since I can't reproduce it and we don't generate mail like that.

(Ideally, accompanied by new test coverage.)

If you want to test it, I'll accept this change or some substantially similar change upstream:

Attempt to improve the performance of the almanac.service.search call

bin/host download --phid <phid> --save-as whatever.sql.gz

After T12652, rCORGI is here on secure.phabricator.com.

Great, thank you so much! :)

It doesn't look like Thunderbird can do this either. I did a "Body" "doesn't contain" "@Mattflaschen-WMF", and it just moves it anyway even if it is a ping (does have an @).

Use of a mail client other than GMail violates international galactic law, so be careful!

I normally do filters in Gmail, which apparently does not support special characters. I'll try to do it in Thunderbird (the main client I use).

As a workaround, you may be able to configure your client to filter on the "body" field containing the special string: @mattflaschen

Something is rewriting your outgoing mail. We do not send mail with a <meta ..> tag (and never have), nor mail which doesn't have a text part (and never have).

It should be in the menu item you wish to make default when you edit the menu

I don't have any pin icon? Where should it be?

Sorry, updated original task with version information. This is just one example message that got flagged, maybe some other messages have plain-text alternate?

Any idea of how to do this on CentOs?