I think D20905 is as good as we're going to get.

The underlying code is still a bit shaky, so let me know if you catch other issues.

In DifferentialHunkParser->generateVisibleLinesMask(), we pass a 0-based array in and get a 1-based ("line number") array out. The loop condition stops us from reaching the last line of the 0-based array.

We have no open customer requests for this and it's very complex, so I don't currently plan to implement it.

Another use case :

I removed the strikethrough in T13482, which mostly moots this.

Remaining work:

D20947 does not implement "Author's packages" as a "Commit Content" field, nor as a "Commit Content (Hook)" field. The reason for this is that getting the modern authorPHID in both cases is somewhat complicated.

The logic here appears to be that gc.auto is set to some value (by default: 6,700). If the number of loose objects exceeds this threshold (technically, if the number of loose objects in objects/17/ is more than 1/256th of this value), it triggers a repack (in a comment, git repack -d -l).

See PHI1613, where an install hit this warning (and resolved it by running git prune):

The issue in PHI1605 resolved itself without apparent intervention, presumably as a result of changes on the CircleCI side. I can't find any release notes to shed any light on things, but this is no longer time-sensitive.

See also https://discourse.phabricator-community.org/t/storage-upgrade-failed-class-phutilauthadapter-not-defined/3468.

See T13478 for followup.

I'm also still able to reproduce this specific variant of things, so it looks like I was too optimistic about T13462 covering this in at least some cases.

A similar issue occurs when the "Visible To" control wraps with spaces enabled. To reproduce this...

This should be fixed by D20943. Note that "Mute" in this context mutes notifications about edits to the object (e.g. "Alice renamed rule Hxxx from X to Y."), not notifications sent by the rule itself.

This went through cleanly.

These changes seem to have stuck.

I thought this was some kind of complicated mess with the regex on line 420, but it's actually an issue with this:

(Since a full implementation here will imply that removing a custom field from configuration may "unmention" an arbitrarily large number of relationships, and we can't easily do that inline or at display time, the ultimately implementation would likely include a more robust version of this script.)

In PHI1602, I proposed a script to "reset" mentions on an object. The use case this serves is:

In jira 8.6.1 settings are now in:

• Administration → Applications → Application links

This page intentionally has a no-Javascript, no-drag-and-drop upload form for users who use obscure Linux window managers that don't support drag and drop.

If you believe you've found a bug in Phabricator, please report it by creating a new thread on Discourse.

Last follow-up -- no, it was not a custom policy. The log of changes to the Project configuration show that the original setting for the edit policy was indeed "Project Members", which seems to indicate that Phabricator was incorrectly preventing new members from editing the Project.

I was unable to reproduce this with a new Project, which makes me suspect the problem isn't a bug in Phabricator. I suspect the Project that was not editable *actually* had a Custom policy with specific users added to it, rather than a "Project Members" policy.

I ran into this issue today as well. The context was a Project created by a regular user a few months back. He added himself and one other user to the Project. He also set the edit policy for the Project to be "Project Members." A few months later, a couple of other users were added to the Project, but neither of them could edit the Project (all links in the "Manage" UI were disabled, can't create milestones, etc.). The users who were in the group when the edit policy was set were still able to manage the group. One of them had to change the edit policy because the newer members of the group could not.

See also PHI1594, which wants:

See also PHI1579.