Thanks for the quick fix! Just updated to latest HEAD and it works fine.

This should be fixed in HEAD. Thanks for the report!

What system are you on that doesn't support this cipher?

We have not seen any evidence that installs which do not use git-phab experience this problem, nor evidence that the upstream workflow is incompatible with small, clean commits.

Basically if git-phab is resolving a deficiency in Phabricator workflows, it'd be helpful to understand why they are being used.

My main point is "organizing a bucket of diffs for review" is not something I would product plan for a feature in Maniphest. I only have a vague understanding of git-phab, but it seems like it's using tasks as milestones? We officially have milestone support coming very soon. Maybe @epriestley has other thoughts.

I think there is a misunderstanding. The problem is not caused by git-phab, it only becomes more visible with git-phab.

I used bin/remove destroy <phid> to destroy the 881 identical diffs, and verified that trimmed roughly 4GB of data out of the datastore.

I think this was caused by the issue resolved by D15072. Specifically:

This should probably happen in the next week, as it's creating moderate storage pressure on db005.

After rCORE538a9808, all new files larger than 64KB go to S3.

3 main issues. ( Just my thoughts. Feel free to elaborate or ignore)

• It does not seem like audit.can-author-close-audit has any effect.
• The audit requestor should be able to close the audit regardless of the authorship of the commit
• I don't understand what the image below means. In this state, the commit still shows up under "needs audit"

Will give that a try. Thanks for the pointer.

There is a setting (default to false) for auditing your own commits. I don't know if that has any affect here.

Let's note this is not an oddball case:

I believe the use cases here are reasonably solved with EditEngine in Maniphest and new Projects (build your own custom form, hide what you want from Marketing, and provide a link to the form on the Marketing project).

Watching a Project looks like it redirects you to the Project default tab, which may be not the details page.

Thanks @chad. I should have read what those meant instead of picking randomly.

Ah sorry, and thanks - for some reason I thought I was on a January release but actually on late December for this install

This was fixed by D14925.

:) @chad I saw this in logs while looking at other issues - Let me know if I should make a Task - I haven't seen any issue/symptom so all I have is an exception.

In T10207#155400, @paladox wrote:

Where do I ask questions.

Where do I ask questions.

I can't immediately reproduce this at HEAD but I'll poke around a little bit more.

We ran into a case where archived packages were trigger builds, which didn't feel right and was causing problkems. I'm not sure what the default behavior loadAffectedPackages should be or what would be most consistent with how archiving is handled elsewhere.

This does not describe a bug in Phabricator. Please read Support Resources and Contributing Bug Reports carefully.

At some point in the future we'll redesign timeline and we'll keep your feedback in mind. Thanks!

After D15093, this should be a little better:

After D15093:

(This is definitely confusing, but I'm not sure what the best way forward is offhand. I'm hesitant to just make Herald always trigger without putting more thought into the issue.)

Thanks, @epriestley (and sorry for getting back to you so late)! You're totally right that this is because I didn't actually update the revision.

No offense intended in the least, we have a large percentage of people who fork Phabricator. I think it lends more to the specific audience of the product in general and that people strongly need to customize internal software for their workflows.

I've retested everything here and in my installation and it seems that this solves all cases re: grouping, ordering, and paging.

Greatly appreciated.

Add a call to ->setPageSize(500) (for whatever value of 500 you prefer) here: