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:

I'm going to get this to being able to build a real file, and hand it over unless you think the rest is trivial. Not sure how this would need to work in the NUX case. Generate an image when PhabricatorUser is triggered? What about old defaults?

crc32 would be fine in this use case too since the requirements are so lax. My version isn't particularly robust either, but should get the job done.

Works great!

This actually seems a little difficult to fix...maybe just make it truncate with an ellipsis?

heh nice. And I didn't even have to cheat by using U+00A0.

Oh is crc32 bad?

Actually, may have found something on "the google". bbs

Since I'm not a real programmer, getting stuck on how to assign something by username. I presume we want every chad to get the same pre-built avatar if possible. I could just randomize it, but that seems not really beneficial.

Yeah, that's a reasonable starting point. I'm sure noone has 99+ task edit forms..... ⛈

And the pencil icon on workboards, the pencil icon on the list view, and the "Edit Task" action from task detail pages would default to "Edit Plant Task", yeah. The workboard change would only pertain to creating new tasks directly on a workboard.

Right now, this menu always says "Create Task..."

For now, we either don't change workboards or just put all the global options into the menu, probably?

@20after4 😆

Calling this resolved since the page is now tolerably bad (~5s) which more or less pulls this out of the realm of critical scaling issues.