@avivey Thank you for the explanation!

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 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:

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?).

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

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?

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:

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.

@20after4 😆

I added the panel back as an option. I'll leave this open until we see if anyone else hits a similar case.

Feed shows stuff that is happening to items with a certain tag. We want to list the items themselves, not what is happening to them.

Instead of Feed?

Yes, we were using the panel to show all items (tasks, revisions, wiki pages, et cetera) tagged with a certain tag.

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.

(They could also go into the existing "Waiting on Review" bucket, but I dislike mixing authored and non-authored revisions in that bucket.)

The actual reproduction instructions are slightly more involved:

I can make a fix so this doesn't fail and grandfather these in if they were in use, but I'd also like to know if people are using these as panels, so I can revert that change if needed.

Is that a panel you were using?

Reading through the diff you mention (D17341 I think?) I see that the query type was probably called "Fulltext Results". Basically the query panel version of this page: https://secure.phabricator.com/search/query/advanced/

Specifically, "Wiki Documents" and "Legalpad Documents" both still are available, but "Documentation Atoms" from Diviner are not.

Can you clarify the steps to reproduce please? I don't know what "Documents" query type is, even reading through the diff that restricted useless panel types.

@jmeador I tried your suggested configuration. The system works, but the server/config/cluster/notifications/ gives the following error instead:

Sorry, yes I am bad cop sometimes. :(

@bcooksley, feel free to mention that you've talked with me about stuff when filing tasks in the future. Like 90% of what shows up here spontaneously is pretty questionable, so unannounced reports get fairly strict scrutiny.

Here's the downstream task: https://phabricator.kde.org/T5406

Note that these steps depend on who is viewing the page (or, specifically, who "Responsible Users" are). More concise steps are likely:

T9372 is the main "Differential Buckets" task.

My assumption reading through docs and tasks is that "Other" means... well, other. It's been both accepted and rejected and I think it's important to convey it's not completely in one or the other state. If you set sticky-accept to false, then it will always go back for review. Maybe @epriestley has other thoughts. I would swear this came up recently though, but I can't find an absolute duplicate task.

Yes, sticky-accept is True.

Is sticky-accept still set to true then? (I think that's the default).

I've now added reproduction steps, including details on customised settings for the Differential application.

Well that's my mistake then! I didn't see it initially.

Sorry, you'll need to provide more detail on what's wrong than repeating your comment. I added the version information to the Task Description.

Also, we need steps to reproduce. the issue locally. There are setting that affect where revisions go after acceptance. I don't know what your install has those set to.

In T12323#213451, @chad wrote:

We need version information on all bug reports.

This report is against Differential.

You also mention "raised the concern". Is this report against Audit or Differential?

We need version information on all bug reports.

From what I understood, if I edit the built-in form, It would apply globally, so I only wanted that field hidden, if it was a new form. which is what I was trying to create.

Have you tried using Lock/Hide Fields to hide the "Status" field?

I am not able to edit the form such that users belonging to a certain group are not able to change the state ie: "close" a task.
Having read into other similar situations ( T11207 ) and reading that your solution is to use custom forms I began investigating custom forms.

What's an example of a specific change you're trying to make which you aren't able to figure out how to make?

commit eec6cd865c854fd00c8de41b8ca8ed0da78760e8
Author: Chad Little <chad@phacility.com>
Date: Fri Feb 24 15:21:23 2017 -0800

You are running an out-of-date version of Phabricator, from February 17th.

Please provide version information for your install. See Providing Version Information.