Thanks for the detailed reply.

Add catfacts tooltip to each application?

It's not hard to add, just curious what the use case is. Most requests have been to "rename" the applications (Differential -> Code Review"), so pulling in built-in tooltips didn't make sense. Maybe we should add tooltip to the "Link" menu type for best flexibility.

In T12174#213852, @chad wrote:

That's expected. When you customize the name, the built-in data (name, tooltip) goes away.

That's expected. When you customize the name, the built-in data (name, tooltip) goes away.

I just noticed that that tooltips behave unexpectedly for application entries in the menu: When the application has no "Name", the default name is displayed as well as a tooltip on mouse-over. When I set a custom "Name", only that name is displayed and the tooltip is no longer displayed.

In my experience, it is very unusual for organizations to have multiple distinct internal groups with different identity providers. Normally, organizations which value SSO and identity management consolidate identities under a single provider, because that avoids problems like this, greatly simplifies identity management, and doesn't require other pieces of software to support multiple providers.

@epriestley : because it's easier to manage everything from a single instance of phabricator. Phabricator has native support for multiple authentication providers, so I don't see a problem with this.

Why are you sharing an instance between two separate groups with separate identity providers?

@epriestley : we need multiple authentication providers because this is a shared phabricator instance, and thus different groups of users need different IDP.

I have a few questions about this, and some ideas for how we could solve it:

It's the ? key on the keyboard. In only works when the focus isn't in any
text-box (If you're using a Mac, that might not be an option for you).

Earlier, I predicted:

Too bad.
Where is this "?" located? you mean the "?" key, or?
If it's "?" from the keyboard, then it's writing in the Search box.

In T4181#204679, @netroby wrote:

The real working example

[…]
ExecStart=/usr/bin/sudo -u vcs-user  /opt/phabricator/bin/phd start
ExecStop=/usr/bin/sudo -u vcs-user /opt/phabricator/bin/phd stop
[…]

That's the expected behavior - see https://secure.phabricator.com/book/phabricator/article/differential_faq/

Alternatively, you can use a test instance at Phacility to verify your reproduction steps against a current version.

Please update your install to a current version of Phabricator (we require all bug reports be against HEAD of stable or master).

I mean doesn't Arcanist track this?

ah poop worth a shot.

D17425 doesn't change my thinking here.

@epriestley Since you added a new "Waiting on other reviewers" bucket (D17425) is it possible to have that bucket cover this case as well? I believe that bucket makes a lot more sense for this case as well then the current "Must Review".

Arcanist understands this is a new topic branch which no associated revision yet,

How?

Go ahead and file something separate for that, I don't think it interacts here.

thanks, sounds great!

Go for it.

@epriestley any objection to removing the "disabled" look here for workboards and subprojects? It's not a consistent pattern with "no permission" we usually use.

If you or your users sometimes use git push to mean "save changes", "make a backup", "share", etc., you can configure "Autoclose" in Diffusion. For example, you can configure only the "master" branch to Autoclose. If you configure Phabricator like this, it will never close revisions when changes are pushed to other branches.

The description of the "git:branch-unique(...)" rule in the "Arcanist Commit Ranges" document may be helpful in understanding why this is hard, or at least hard enough for me that I was unsuccessful in producing a "do the right thing" or "do what users expect" behavior when I tried and we ended up with "base" instead:

Maybe a better path forward is this:

Also, how do you expect to arc to distinguish between these two use cases, each of which some users prefer?

The general "why of the why" is that if "git push = publish" is a valid assumption, and users "git push" a series of changes, they expect corresponding revisions to close -- even if they've rebased, amended, etc., those changes. We try very hard to find revisions to close when we discover new commits to meet that expectation.

Arcanist understands this is a new topic branch which no associated revision yet,

By default, Phabricator assumes that git push means "publish", and that it is ONLY used to publish the final version of complete, reviewed changes. If you haven't already seen it, this post describes this in more detail:

I think you can use imagecolorallocatealpha($img, $r, $g, $b, $a) to do it for you. Note that alpha is 0-255, not 0-1.

Expected flow:

• have a topic branch and call arc diff
• create a new topic off the first one then call arc diff again
• Arcanist understands this is a new topic branch which no associated revision yet, so it does arc diff --create <first_topic_branch>

I understand the "why" but not the "why of the why" if that makes sense? What this means is that revisions might be closed in what appears to be unpredictable to users if they happen to push their topic branches to the repo AND have merge commits on them (that's the issue no?).

If it's not simple, I can probably fake border colors with builtin colors we use.

I'm fumbling with GD, I did try solid color borders, which work fine, but are overkill (millions of options). I wanted to go back to RGBA, but not finding a good reference on converting rgba(255,255,255,.4); into a GD friendly color.

Here's what I just did on a new Phacility instance:

Great, thanks! I haven't come up with any other major concerns myself after considering this for a couple of days, and expect to move forward shortly.

"Overall, I think this is the model we should continue under, and task subtyping should be implemented in terms of views of a subset of fields."
"In the current model, you choose a task type first, by selecting a "Create" form, not by choosing from a "Type" dropdown within the task. "

Or maybe a simpler question is: when you run arc diff without arguments, what is the complete algorithm you want arc to follow to figure out which commit range you intend to send for review?

Is this behavior clear after finding "Explain Why"? Which parts remain unclear?

Based on the output, what do you believe arc is doing? What do you think it should do instead? Which part of the behavior do you believe to be a bug?

Interestingly, using arc diff --create to force create a new revision generates one with a patch that still contains the diff of the original topic branch. The solution is to force arc diff to use the tip of the original topic branch as the base whenever calling arc diff while on this secondary topic branch.

In T12321#213543, @epriestley wrote:

This does not describe a bug in Phabricator. I've reviewed the documentation and believe it is already sufficiently clear in describing how to accomplish what you're trying to accomplish. Particularly, I don't see anything in the documentation which is misleading, or suggests that the workflow you're using is the correct way to accomplish your goal -- it isn't, and the documentation describes the correct workflow. See Support Resources for other support resources.

Clicking on "Explain Why" shows:

We didn't find a "Differential Revision" field in the commit message. This commit and the active diff of D127 had the same commit hash (70bfb4dd58c56a37296b00632113bd01d9facb83) so we linked this commit to D127.

Oh, it looks like pushing the topic branch when it was at the merge commit resulted in Diffusion auto-closing the Differential revision? This would explain the arc diff behavior reported above, but then the question becomes, why did it auto-close?

Hit ? to see a list of all available keyboard shortcuts.

I've deployed everything so I believe this is now resolved. I'll keep an eye on it going forward.

oooh, yes. That is cool! Does it has a keyboard-shortcut?

The pool appears to be scaling up and down properly now. I'm going to deploy the fix to the secure and repo tiers since it may affect all instances.

I'm picking D17433 now and sending it to admin.

I'm picking those to stable and sending them to production now.

• The SQL templating should define some new variable like {$FULLTEXT_ENGINE} which evaluates to the appropriate engine at runtime.
• The Quickstart SQL generator should replace the raw engine string output by the build + dump process with this variable in the affected tables. This piece will be a little hacky, but I think that's unavoidable.
• The Quickstart SQL should be regenerated.

The issue might be caused by resources/sql/quickstart.sql still creating tables with ENGINE=MyISAM.
As there's no way to initially create them with MyISAM and then migrate them to InnoDB in case MyISAM isn't supported at all, another solution has to be found.

In T11741#213219, @Firehed wrote:

Just a note for the above - the initial DB seed script will need to be updated accordingly as well. Right now, trying to perform a clean install on a 2nd-gen Google Cloud SQL instance (which has the above limitation) simply errors out when it reaches one of the tables coded as MyISAM.

If I drag and drop I got a different error:

In T12330#213674, @chad wrote:

Do you think it makes sense to grey out "Subprojects" at all or have a tab for it when there are no subprojects?

Do you think it makes sense to grey out "Subprojects" at all or have a tab for it when there are no subprojects?

Oh wait, this is the unit tests failing. Nevermind

I believe the semantics are consistent, but let me know if I'm misunderstanding or you're seeing something different: