In T5029#210026, @bcooksley wrote:

@epriestley my apologies for this. I had sent out a memo previously asking for everyone to file tasks on our Phabricator so that I could co-ordinate things from there. It seems some folks have missed that, so i've now resent it to a wider audience.

Usual "here in my machine works fine".
Hereby is screenrecord to convince you
http://srecorder.com/s/3huk
Or just give a joker where to look after for raised flag of locked task or like that.

For anyone who doesn't want to wait for this to be implemented, here's a Tampermonkey script to do it: https://gist.github.com/lyahdav/30fabcfb2856a28d320114922c91a1e3

Cool, this would be great!

The general headers/sections are mostly scripted now so they should be fairly consistent, but I'm still editing the actual markup at the end of the day.

I'm good with the current balance of the changelogs - the one thing I think would be nifty is being able to accumulate the Upgrade/Compatibility sections across changelogs, for sites that aren't able to upgrade weekly. I was considering making a script to scrape that info but haven't had a chance to sit down for it. Also it'd be relying on the changelog format to be consistent (seems to be pretty darn consistent).

I think we currently get about equal amounts of "your changelogs should be more detailed" and "your changelogs have too much irrelevant stuff" feedback so I'll take that feedback under consideration but don't plan to make changes unless the overall balance of feedback shifts substantially in one direction.

We support viewerprojects() elsewhere but it isn't currently a component of the "Auditors" datasource. See also T9362#207080. I'll file a version of T9362 for the "Auditors" field.

More generally: I think your decision to not try to migrate saved queries makes a lot of sense. In lieu of that, I'd like to cast a vote for more prominent mention in the changelog. It would be great just to see a note that some queries would break and some hints on identifying and replacing/repairing the broken ones.

I've hit the same problem that @cspeckmim ran into. As best I can tell, in the new system there's no way to quite replicate the behaviour of the old 'needs' or 'problem' audit queries. The closest attempts I've come up with so far are:

• query for Audit Status = Audit Required/Needs Verification and Responsible Users = viewer(). But that includes results where the user is the diff author, not auditor.
• query for Audit Status = Audit Required/Needs Verification and Auditors = viewer(). But that misses results where user is a member of a package or project auditor.

I think this would work if I could query for Auditors = viewer()/projects(viewer())/packages(viewer()), but it seems the functions aren't composable (at least in the UI).

I tried removing white space: nowrap; (from one of .phabricator-action-view button.phabricator-action-view-item, .phabricator-action-view-item) in the browser inspector on FF and it looks like it goes back to normal (even when expanding).

Yeah Chrome is fine as well.

Do you have a rough suggestion on what to do with badges.search? Seems like noone would use these feature regardless.

I'm going to merge this into T5029. This is an extremely low priority for this upstream because this workflow is virtually unheard of among full-time software development professionals (see "Target Audience" in Contributing Feature Requests) because it is inherently error-prone.

How do you make guarantee that unrelated, simultaneous, uncommitted changes in the same working copy do not interfere with each other?

Maybe a better way to explain Phabricator's philosophy is that it's build on code quality. That is, if we have to equally choose between developer efficiency and code quality, code quality will win because we feel code quality leads to greater long-term efficiency. It means less likelihood of wasting reviewers time, or chasing bugs, or missing issues because of easily catchable programmatic mistakes. Is it a great workflow if you're just fixing a typo in a document file? Not at all. But 99% of revisions are not typo fixes. With a commit, we can run builds, show reviewers full context diffs, allow for arc to patch diffs, allow for chain of custody and so on.

How do you make guarantee that unrelated, simultaneous, uncommitted changes in the same working copy do not interfere with each other?

The problem to be solved is that workflows as I've tried to describe aren't possible. Workflows where there is no official policy that changes first have to be committed, signed off or whatever before they can be considered for inclusion upstream. Or if you want, workflows in a more relaxed community with smaller and larger contributions coming in from a wide variety of users and developers not all of whom are experts in using git, svn or what have you.

I guess this is pre pre-commit review?

We want to know the problem you feel that feature solves specifically, not just that you want it. You can run patches manually or run arc diff --preview to just preview changes. But offhand I don't see any workflow benefit to reviewing non committed changes and don't recall any requests for such a feature.

Sorry, the Root Problem was clear enough in my head but apparently not explicit enough in the OP. I hope to have addressed that now.

Please use Ponder or Conpherence if you have general questions about using Phabricator. If this is a feature request, it needs to state a root problem in order to be accepted. See Contributing Feature Requests and Describing Root Problems.

I've followed the steps you listed above but am not able to reproduce the issue. Do you have more information you can give us on how to reproduce the bug? Without reproduction steps the upstream cannot move forward.

Same problem here, any help?

Thank you for the very thorough reply.
That's not a big deal and it certainly can wait!

In our case these are commits from landed Differential diffs. Permissions
for the web user are there and correct, but I'm not sure I understand all
the details around the daemon vs. web user, and the daemon is doing the
work for this git commit parser.

Thank you for your quick reaction (and sorry that I didn't reply sooner). I think a black color with a 1px black text-shadow looks better. The blue is confusing (it sort of looks like a link).
So I suggest:

.phui-document-view .phabricator-remarkup .remarkup-header strong {
  color: #000000;
  text-shadow: 0 0 1px #000000;
}

I've implemented the sudo approach at some point - P2016 - and I think it worked alright.

mkdir: cannot create directory ‘/var/storage/3f/49’: Permission denied

I have to report a possible bug as asked in Q584.
Message for editing locked task when create new non-existing task:

... and then there was one ...

I haven't been able to reproduce this locally by artificially making services unavailable or connections fail. Debugging this in production will require momentary service interruptions on admin until I can narrow things down so I'm going to wait until off-peak to poke at it.

Occasionally, even after running the re-parse command, the basics of the commit will import but the content itself will not. A phd restart will almost immediately allow the commit to then import.

But other interfaces around Phabricator are not going to fair as well, just FYI.

Server side reduces this quite a bit:

We can look at the server side issue, but we already have text-overflow on this element, so it's not going to resolve the core problem.

I agree that long project names might a problem on its own - but for now this was a compromise I had to make to compensate for the fact that projects are just "generic" containers which can't be further classified to distinguish between ACL groups/projects/tags.

This is working as intended. If you choose significantly long project names, many pieces of Phabricator will naturally become less useful and more difficult for you users to use.

More info: the commit contained binary files (executables actually).

We now have one that's failing even when forcing a reparse:

@20after4 : Ah. So by default, everyone just gets a "create task" option, which would never use any custom forms or subtypes. That does seem to resolve my concerns (although I still think it would be cool for phab to behave differently depending on which project(s) I was viewing).

Is there a way to recall the logs from a failing task? Is there any value in providing the logs for the successful task? Not really sure what to say here besides that it's a consistent and random issue on our repositories. When we run the trace, it then "bumps" the task somehow and things succeed, so it would be difficult to provide detail on an error.

There isn't enough information here for us to reproduce this, or even begin.

In T12363#214538, @chad wrote:

What are you attempting to do here or was this accidental?

What are you attempting to do here or was this accidental?