:) It's not a very important bug, but isn't it still a bug that the button shows up?

Got it.

I was expecting to see exactly the view in your screenshot -- changed files expanded inline, and moved files described as such.

I wonder why I had a different behavior:

I suspect that diff.renames has the same behavior from recent versions, just that it is enabled by default.

Wow, that's strange. Is it possible that you have a different setting for diff.renames?

Yes, I'm not claiming that git can somehow not show actual changes, just that it doesn't show file renames. This is what I was doing:

I was thinking of what you see when you then do git add, git commit, and git diff HEAD..HEAD^. I might be using the wrong terminology perhaps

I can make it a feature request. I marked it as a bug because git diff will return something that's pretty small in this scenario.

We'll take this into consideration and keep an eye open for other feedback,

In T11530#192966, @chad wrote:

Maybe create a bot user called @shipit to trigger herald? Mentioning users CCs them to the object, but mentioning projects does nothing currently.

A potentially less controversial fix for the 2-step entry issue might be to add a keyboard shortcut that will add a task to the last used column.

Herald firing on other things: T10109

Commandeer is a pretty infrequent action so this doesn't matter much, but out of curiosity could I avoid this with a better Herald rule? I guess I can try Changed file content matches regexp '.'.

I have read https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/ , and it briefly addresses this:

Yes, that works if you decide to collaborate ahead of time. If you decide to "stack" on top of a revision under review, you have to either

Hmm, but that's not quite the same thing as what I'm asking (I think) -- in my scenario a pair of authors are adding commits to a branch off master (imagine it's a refactor and we're fixing different tests), and the stack of commits is reviewed in one PR. I know I can do this today by just creating a remote branch, collaborating with someone on it, and doing no code review until all the commits land (at which time one of us creates the Differential revision).

Could you point me at an example revision to see how this looks?

I agree that there *shouldn't* be any extra cost purely owing to having more fields if I'm only editing one and it is default-focused, but I'd argue that having a more complex form will still slow humans down (at least initially).

Is this really "Make Workboards look and feel exactly like Trello"?

More fields means

Starting to try out Workboards (we're coming from Trello), and I felt the absence of this feature as well.

Awesome! I appreciate the quick fixes!

slightly related: there's some confusing naming in the result for harbormaster.querybuildables:

This is resolved on my end.

Please close - I figured out how to change the username. Not sure why I missed it the first time :(

Here's github's version of this, as an example.

@epriestley - I currently don't have the permissions to edit feed.http-hooks -- it claims I don't have permissions to manage the "finxpc.phacility.com" instance, however I'm apparently an admin on it. We (Danny, the person who set up the instance and I) have also been unable to figure out how to grant me any different permissions - could you please give us a nudge in the right direction? Danny also appears to be an admin, same as me, but has permissions to edit that variable.

In fact, this also happens with other panels. Basically the top right panel will always be duplicated to bottom left.

I haven't seen more segfaults since I switched.

Thanks for the pointers, I'll try that.

I don't want to distract this too much with the "automatic land on accept without author intervention" case. Is there a way to achieve the less controversial "author-triggered land without going to the CLI" case?

In the common case, I'm not arguing against that principle -- "closing a revision" in my example above is a trigger initiated by a human. I'm just not requiring them to switch branches and type arc land. T182 supports this thinking, it seems.

Are you manually closing the revision as a signal that the revision is "ready to be landed"?`

Yes, that's what I was aiming to achieve. Is there a better way to do this?

It perhaps does, I'm still trying to figure all of this out. So a harbormaster http request would notify the bot to deploy, and a herald rule would trigger that request. If we wanted to deploy multiple revisions in one push, we'd just buffer the http requests on the deploybot's end.

I will add my vote for a small subset/version of this, ie. hoist inline comments and their "done" state into an easily perusable checklist.

The other thing that was confusing was that "Config" didn't actually have all the settings -- some settings are in Config, some user settings are in my "profile", some other settings are in individual apps. It would help to consolidate these into one directory.

$ php --version
PHP 7.1.0beta1 (cli) (built: Jul 25 2016 13:58:06) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies

That might explain it (not sure how I got on the beta, wasn't aiming to). I've switched to the 7.0 version, will see if that fixes it.

Maybe link it in the "Explain why" dialog?

Ah, sweet. Thank you!

Not claiming it's better (it seems to do a lot of what arc lint does, minus the ability to amend), just that we already have linting set up through it and have custom linters implemented in that framework.