A similar thing came up for us recently: "vote for a project name or write-in your own!"

Every... day...

@filterfish, I'm using that patch as-is on an x86 system, and it works for me. I suspect that the real solution is not to run phabricator on systems that the core team doesn't test on, so we're planning to move our install to x64 in the near future.

Yeah, I get it. I didn't mean to re-open it, that was just a side effect of me modifying the description at the same time as you'd closed it. My "open" state must have overwritten yours.

I was seeing my specific problem by tweaking viewport width, not by zooming, and that problem is already fixed on this install.

At certain resolutions:

Short of an overhaul that won't be available "for a long time", here are the minimal local changes one could make to get notifications working:

Awesome! Yep, 'type' => 'string' fixed it.

They say that the look is the best part of the cursor.

Logging each function call, I'm seeing this:

Not really. But I cobbled something together via the bot, which suggests that this is this stack trace:

Happens to me on Chrome/OS X with Cmd+F, too. Here are specific steps:

@vm: I've opened a separate bug for the "already-landed dependency" case: T8419.

I've added more details at T8503

Here's what it looked like in the apache logs:

See D10671 for an example of an inline comment that doesn't wrap.

Testing inline comments in table

Seems weird, primarily due to lack of standardization. Would // and # both work? Or only one of them? The decision winds up being kind of arbitrary.

In situations where ghost comments wind up doing more harm than good, it might be nice to hide them via a keyboard shortcut.

One of my main use cases is making sure that inlines survive a rebase, which we use frequently due to how unforgiving arc patch is. If that results in actual hunk changes, I'd still like to see the inline, and decide for myself if (1) it's still relevant, and (2) it still targets the right lines. If it's no longer relevant, it would be nice if I could "dismiss" it, which would stop it from showing up. If it no longer targets the right lines, it would be nice if I could "re-target" it.

If you could magically confirm that a ghost inline still makes sense on the updated diff, then auto-expanding it makes more sense to me. The main utility of folding it by default would be to minimize the damage of bringing forward "stale" inlines. @avivey made a good point that this could be integrated more tightly into the "Done" state.

I don't see any examples anywhere that have a whole inline "conversation" on an older diff. Do those conversations get folded to one line, or does each message get folded individually?

I would prefer the "fight the good fight / make it easier to do the right thing" approach.

Ah, requesting review auto-accepts in this situation? I didn't realize that, thanks.

Abandon doesn't seem right, because it implies that the changeset is being abandoned. I just want to abandon the changes I was planning, and land it as-is.

Maybe I'm misunderstanding how arc.autostash works, but I don't think it does what you claim. It looks like it just runs git stash, which ignores untracked files.

I agree with @joshuaspence. Another edge case that falls under this umbrella is using the back button, which used to scroll down to where you were when you'd followed some link.

Here are some thoughts on inlines, based on our usage:

I'm seeing the same thing (what @kparal said) in Chrome 40 on Ubuntu.

Fails on x86:

If you're talking about tagging a task, that's generally done in Phabricator using "Projects", which are like tags on steroids. (They're a little harder to create than in, say, JIRA, but otherwise work basically like tags/labels.)

See T5222 for a related pylint discussion

Sadly, I didn't cause this. The guy that did this created it using msysgit's version of vim. He gets into all sorts of trouble. I guess I'll classify this as "obscure user error" for now, but I'll re-open if I see it again.

Summary of a conversation I had about this with @epriestley on IRC:

I haven't looked at the code, but, to my understanding, the way arc patch Dx actually works (on git) is roughly:

The cmd /? help page says that the special characters that require quotes are:

Additionally, $this->getPaths() returns paths relative to the root of the project, which don't actually resolve if arc unit is run from anywhere else.