I'm going to merge this into T9028. Specifically, D16133 rebuilds the summary table after any commit becomes unreachable, which should produce the correct commit count and other summary details.

D16134 just hard-codes phabricator/ tags as untracked, which should minimize collateral damage.

Yeah, the actual rule D16129 implements is this:

they are mine T.T

We could do posts too, but I only have 3 arts so far, so blogs seemed easier to start with.

I've deployed this and configured this server to use AES-256-CBC, although I haven't retroactively migrated existing data.

We can't reproduce this and haven't seen other reports of similar issues (including from other installs of greater size and complexity), so we have no way to move forward on this.

Bookkeeping; there's no longer an external driver for this.

Just bookkeeping; this doesn't have an active external priority driver.

Just bookkeeping, this doesn't currently have external priority.

This should be fixed at HEAD of master. Let us know if you're still seeing issues after updating.

T11044 makes this both more relevant and somewhat easier.

"Autoclose" and "Track Only" configurations are limited to branches, and do not account for arbitrary tags/refs. For now, I think we can assume tags are always autoclose/track, but may need to refine this in the future. I'd ideally like to replace autoclose with "fork" (T10691) rather than introducing tag(regexp(...)) or whatever, but that may be a long road.

To revive deleted commits when they are re-pushed, I think it is sufficient to ignore deleted commits when filling the discovery cache (PhabricatorRepositoryDiscoveryEngine->fillCommitCache()) and allow recordCommit() to detect existing commits and revive them.

Current state of the world after D16108 is:

Thanks for the report! This should be fixed once D16128 is reviewed, likely later today.

Thanks for testing, that's quite helpful.

Generally, I think resource autorelease (using @hach-que's rule) is probably the shortest pathway forward here. You'll still have a fairness problem, but you should get better utilization from the pool and be deadlock-proof on "A", "A" type acquisitions. This also tends to trigger less adjacent work than new resource types would.

Being completely fair also means we must execute without parallelism, because if we start position 2 without waiting for position 1 to finish it might win, and this could keep happening forever.

The expectation is that allocation should generally be fair ("first come, first serve") when no allocations fail.

You can determine both of these from the harbormaster step dependency tree.

I'm planning to do this:

See some prior discussion in T10081, which I'm going to merge here.

I think this also increases the chance that users accidentally disable or misconfigure (e.g., by misusing Match user) administrative sshd by requiring more extensive changes to its configuration. Users locking themselves out of the host is the worst outcome of a configuration attempt by a huge margin.

Can you provide:

@bizrad6 Thanks, I think D16118 should fix that once it lands. Sorry about these issues, the actual global stuff happened at the very end of the settings changes and I didn't test it as thoroughly as I should have.

My tentative plan is to define keys in local config with some sort of structure like:

Cool, pretty sure I've got a repro then -- real fix coming up in a second.

Ah, I think I've got a repro. Does this "fix" it?

There's a very small possibility that D16110 fixed a race condition which was causing this, but that seems like quite a stretch.

GitHub does not appear to ever render absolute time. Instead, it renders relative times like "5 hours ago", etc.

Is the behavior you want the same as @vinzent's desired behavior, your phone's behavior, and your laptop's behavior? That is, blindly trust client timezone unconditionally, without prompting or notifying you? From the original description, it seemed like you wanted essentially the opposite behavior.

auto-adjusted based on location

why not using the browsers timezone by default and giving the possibility to set a static one in the settings if really required (without this message popping up)

"Adjust timezone" dialog doesn't have a way to cancel/ignore

Or, perhaps more specifically: why do you want to change your machine's local timezone, but not change Phabricator's timezone to be consistent? If you just didn't want to change your timezone at all, you could leave everything in PST while in London and your system clock and Phabricator would both remain in PST, but you did change your system clock.

Why don't you want to change your timezone?

Catching a couple more funky diffs:

I enabled Google for central auth since I think everything we need for it to work already works fine in the cluster, although it's possible some of the invite flow stuff is a little shaky.

I believe this is fixed now, but reproduction has always been somewhat elusive so I'm not completely certain. Please let us know if you still see issues after updating. Thanks for the report!

This commit now appears properly in the history view on this install, so I think the issue is resolved:

I can't reproduce this -- rGITTESTaa541e7b324424e201c124dc58588c33e48d8bf5 seems to work fine for me.

If the "Audit" setting for packages had three settings instead, would that solve your use case?

Thanks. That trace is consistent with the one I was able to reproduce, so I suspect the changes above fix this. I'll leave this open for a bit in case anyone else shows up, this fix is the kind of fix that's likely to have spooky side effects.