Does using --max-pack-size to reduce the maximum packfile size really let Git "checkpoint" after each packfile, so the process is effectively resumable?

PHI1655 identifies a specific case where enormous packfiles may create problems:

I have some code which runs and looks plausible (i.e., not covered in piles of callback garbage), at least:

See https://discourse.phabricator-community.org/t/data-truncated-when-pushing-into-repository/3586/ for what is likely to be a related issue.

The real root cause of this issue may have been a locale setting which uses comma as a decimal separator, see T7339.

@epriestley As perhaps an example of another use case, in my workplace we needed, amongst others, the following lists of Maniphest tasks:

1. assigned to the viewer, regardless of the author,
2. authored by the viewer, without self-assigned,
3. subscribed by the viewer, without (1) and (2).

(1) is obviously trivial (there's already a built-in query), but the other two seemed to require custom "NOT" filtering. Of course, (2) can be solved to an extent by using "Group by assigned", but it's not very convenient. Because I tend to self-assign most of the tasks that I create, the ones that I have assigned to other people quickly get visually overwhelmed by the large group of "Assigned to kerberizer" (not to mention that with my username this huge group tends to get in the middle of the list).

Here's an actual example of loadHardpoints($objects, $hardpoint):

Perhaps another approach that could be considered, doing the colorizing in the browser using something like highlight.js (https://highlightjs.org/). This, of course, puts the CPU burden on the end user instead of the server.

In the specific case of the Hardpoints, we currently often have code which loads objects but doesn't do anything with them. For example, most Query classes use didFilterResults() to fill things-that-sure-look-like-hardpoints, but few do anything with the results.

I'm going to mark this as resolved, since:

The core idea in D5104 + D5105 is that $future->resolve() and id(new FutureIterator(array($future)))->next() (like, roughly) execute meaningfully different code paths.

Somewhere in experimental or wilds, I introduced ArcanistConduitEngine. This has some weird fake future stuff going on, so this is probably now ripe.

Couple of notes on the state of affairs here:

As of early 2020, this change works:

JIRA did this (changed how accounts are identified) again recently (key is now accountId), see T13493.

One minor issue with this is that there's some duplication when the commit Fixes Txxx and the associated revision already has the edge (which is very common if the commit Fixes Txxx, because the revision almost always also Fixes Txxx):

To follow up on this:

I can't find any changelog in any version of Git which mentions the introduction of %B. The %B behavior was introduced in this commit in March, 2010:

See also PHI1605 (internal), which provides some evidence that:

I landed everything so far to master. The new behavior in master should be:

I stumbled across what appears to be a very mild security issue in JIRA that impacts this flow. I've reported it to Atlassian's bug bounty program here (this link may or may not be visible to anyone else):

This change sequence is almost ready to remove readers and writers to accountID, but there's still a unique <accountType, accountDomain, accountID> key on the table. Removing accountID writers completely will mean that the second user to link an account of a particular type (say, an Asana account) will run into a unique key error (since they'll write a second "Asana" account with the same empty accountID as the first "Asana" account).

In T13493, PhabricatorExternalAccountIdentifier could also benefit from this null policy behavior.

These callers use accountId:

I think the patch above is a piece of the solution here, but makes behavior worse for some installs: installs with a version of JIRA which returns both key and accountId will have worse behavior under the patch than without it (since it will break all the existing account links immediately). It also doesn't smoothly migrate these installs, even though it's theoretically easy/desirable to do that.

Ah, thanks. Yeah, I think that's reasonable. I'm sure some other things can still be cleaned up -- like I changed the "Subscribers" UI a little bit recently, and it could now handle disabled users more clearly:

IMHO this could be closed as resolved these days.

When a user logs in to "new" JIRA, we also can't easily tell if they have an existing account link based on the presence of an accountId.

I'm changing the minimum required version to PHP 5.5; see T13492 for 5.5-specific followup.