Check if I'm set up currectly re:staging...

For record-keeping, this was asked again in https://discourse.phabricator-community.org/t/469

(Mentioned in https://discourse.phabricator-community.org/t/run-herald-rule-for-each-push/299)

I'd guess your origin is a GitHub fork or something?

The build failure looks like some setup issue - it failed to start.

If that suggestion looks valid, I'd be happy to implement it (I'm thinking "Add RemarkupCaption into Control, render above actual field", and maybe "migrate Caption field to use that too").

I could totally be imagining that.

If it matters, my laptop is actually 13" with 1080, but it's only because the store said they don't have a smaller version.

¯\_(ツ)_/¯

I'm assuming this is called for each xaction type?

not editing, just got here from email + clicked "view history".

Is this "normal side navigation" used anywhere else? It looks a little strange:

Thanks for the writeup :)

So, all three major VCS had the exact same CVE, which was "we invoke ssh command line, don't sanitize input, and don't specify -- anywhere"?

😀

Also Pygmentize and nodejs?

I was thinking that the first time they log in, we just take the browser timezone and set the user config to that.

ok, that explains the Versions field - it appears only to increase when updating the Body and not the Preamble.

Ok, so that was one hack too many :)

Renamed the upstream to check sanity

Did I go to far over the bend for this?

Yeah, I renamed origin to upstream, and (it's the only remote right now).

I got a SKIP STAGING Unable to determine repository for this change. warning, which I think was supposed to say "unable to determine staging repository...", which I'm not sure why, because it knows it's rP?

It might also make sense to update U15 to point to the new thing.

Also, have you tried looking around the git community? I was always under the impression that SSH should be faster than HTTPS cloning, or possibly using the same protocol.

Methinks that the Rube Goldberg solution for this would be to get unittest.skip to have another argument with a task number, and then validate with lint/runtime that it look like T1234. And then maybe grep the body of the ticket for the filename.

Don't most places consider "Can Edit" to be weaker than "Can View"?

Is that a bad url that's contained in the commit message? Is the commit message literally Change the recognised url from showcase://?ITEM_ID to showcase://item/ITEM_ID where ITEMID is the ID of the showcase item?

So probably, the actionables here are "Allow HTTPS in Phacility"?

It looks like it's the same speed?

We don't maintain that instance. Please contact llvm.org directly for it.

Probably resolved.

in T6722#197239 I had the same problem with "land revision from Web UI" :)

I can't think of any solution to this short of full policy + complex policy rules such as "users that share project/space/payment account/instance with this user", which is complex (and probably slow to compute, or requires lots of extra stuff to maintain).

@chad, @epriestley - I think this is a reasonable question.

I'm not sure I understand something:

(I've extracted the graph issue to T12840)

In T12804#227133, @nickhutchinson wrote:

Equally valuable as "what branches contain that commit" is "what commits are in the branches we care about". For us, the answer to this is the commit graph -- it's a succinct, easy to understand representation of our branches and their relationships.

I get that if you only have one primary branch, there's not much value in the commit graph. Similarly, if you're not linearising history, your commit graph will be so messy as to be meaningless. But if you do have the requirement to actively maintain several releases of some B2B software package and have a well defined branching strategy for your team to make this happen, then the commit graph is meaningful and unexpected merges will stick out.

I think we have it documented somewhere that "we have developers who refuse to learn git" is considered a bad reason to ask for a feature, and you should maybe consider solving this issue with some workflow changes.
Note also that in your link, epriestley says

In projects which do not linearize history with arc land + squash merges, I believe this feature is virtually useless because many commits are merges and visualizing the repository isn't very informative (the history has so many parent/child relationships that none of them convey much of anything).

Two questions pick at me:

1. Which editor did the user use to add the ZWS in? Any editor I remember does something to warn you about it.
2. Why are there Unicode characters for "goat" (🐐) and for "cooked rice" (🍚)?

T929 is probably the earliest request for this feature :)

Maybe every object should allow a cover image then?

I think that ArcanistTextLinter actually checks for ASCII right now, so it should be easy to enable for this case. See also D6050, which discusses selecting encoding for it.

also, T8407 maybe fits here? I think it's mostly a UI issue now.