This is also extremely silly, but I sometimes do it because I'm dumb and have muscle-memory for ⌘+1+⇥+⌘+V+⏎: searching for an object URL doesn't jump you to that object URL, but you probably meant to put it in the other box.

@johnny-bit Sure, feel free.

Yes. We'd retain the base revision information during parsing in differential.createrawdiff, and it would remain available later in arc patch.

@epriestley - Just to clarify, with the solution you're suggesting that would mean the diff created using differential.createrawdiff → differential.revision.edit would result in arc patch of that revision applying the patch to the base revision parsed from the raw diff from hg log --patch --rev <rev>?

A related issue is that when you use {Fxxx} to embed an image as a thumbnail, we can fail with a default thumbnail if:

Another user coincidentally ran into some questions here yesterday; I'm going to retarget this to take a stab a improving the documentation/description.

Thanks, I'll just keep an eye on this ticket and switch whenever I need to.

Right, you can't user.search for the currently logged-in viewer. If you don't need to know this (you already know the right username or PHID) and were just using user.whoami for convenience you could switch today, but, e.g., in arc we rely on identifying the logged-in viewer with a Conduit call.

I assume based on your comment there isn't a good replacement for whoami until viewer is available on search? (aka I'll keep using whoami until viewer is available as an input to search)

The pathway forward here is probably:

I'm thinking that the "faking" suggestion from above is likely the best situation given user mistake of using an initial name that is undesirable at a later date. I had wrongly thought that the remarkup was "internal form" already, which was a poor assumption.

Doesn't sound like there is anything the upstream can do here.

Hm... the way we our systems folks have it installed it's apparently not a git repository. However, I was able to look in the src directory and found those lines in workflow/ArcanistCommitWorkflow.php. I'm checking with the person who ran the command that prompted me to make this feature request.

itsamystery

Hi! I'd love to submit diff + better test cases for this case. I have 3 additional test cases and better character class for whitespace.

The patch above fixes the issue, but as you mention, double newlines are also considered whitespace, which is pretty bad and removes every empty line.
Additionally, \r is also covered by \s, so the patch above creates a new issue that is very similar to mine: the rule LINT_TRAILING_WHITESPACE fixes line endings even when the rule LINT_DOS_NEWLINE is disabled.

I cancelled and reinstated E1486 to force a cache clear with the new code, which seems to have resolved this in production.

Okay, all better now.

I have to cancel your vacation again sorry

Expected output is similar to this:

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).