Thank you !

After D20194, expansion of tabs now uses the correct rule (expand tabs to the next tabstop) instead of the old rule (hard-coded replacement with a fixed number of spaces).

I'd propose for simplicity that the focus switch from largefiles to lfs support for Mercurial repositories. lfs has been added to Phabricator for Git already T7789 and it seems that there'd be less work involved to piggyback on that.

A related issue here is exemplified in https://discourse.phabricator-community.org/t/importing-libphutil-repository-on-fresh-phabricator-triggers-an-error/2391/, which basically amounts to:

As of D19748, I'm not aware of any change of size X that requires more than 8X bytes of memory to parse. This isn't ideal, but it's a fair bit better than the 32X in the original report.

See PHI1015 for a slightly meatier explanation of this issue.

So I don’t see why that logic would be necessary. ... Pushing to the referenced branch never changes the ref to the branch itself. Only branch deletion does/can.

If the answer to (2) is "yes", we should detect that a commit deletes the HEAD ref and remove HEAD before accepting the commit. This may be quite difficult if hooks don't get to run before the HEAD check runs.

See also PHI1011. I think the fix here is likely easy, but I'd like more clarity on:

(Must Encrypt Mail is a magic meta-tag for testing the feature, not an organizational tag.)

See T8962, somewhat. When receiving inbound mail, we could decrypt PGP messages and verify PGP signatures.

The existence of alternate ... code signing standards would motivate

I don't expect we'll need to do anything here, mostly just wanted to be able to dig up a list of these if something does come up.

Are colons (:) supported between the keywords and the objects? E.g. Fixes: adcbdef or Depends On: D123?

P2110 has a very rough cut of this.

I think you can cherry-pick those changes safely. I suspect further changes connected to T13211 and/or T10884 in the near future are likely to be difficult to cherry-pick, though, so ideally you should try to upgrade.

@epriestley : our current phabricator version is c46be2a70b4db72d61e76690ef095384de2c3f91 that was landed on 04/13, will there be any issues if we directly cherry pick the recent two versions without pulling any other changes?
rP51073b972ece: Try to route cluster writes to nodes which won't need to synchronize first.Wed, Oct 17, 3:08 PM
rPbc6c8c0e93a7: Explicitly shuffle nodes before selecting one for cluster sync.

PHI860 is a close variant of this and discusses periodically running git repack. Most concerns around git repack are likely similar to concerns around gc and prune.

I expect to add flags like "this doesn't block undrafting" and "this build doesn't matter" soon, and then possibly refine those. I'd consider revisiting this after those deploy, but am not excited about formalizing the idea of "only some of your tests failed so it's okay" or adding a check for each build (since this won't scale very far). The tooltip is reasonable but I'll just turn that into a note on T13088.

The root use case here was a desire for a better sense of how often certain rules were firing, and we improved the push logs instead to address this more directly (D19555, D19556, D19557).

The workaround does not work for me on Debian 9.5 with OpenSSH 7.4p1. Actually I am surprised this worked for anyone, since the issue appears to be that the buffer of the pipe between ssh-auth's stdout and the parent's stdin is being filled, hence ssh-auth blocking at some point. It should not matter how fast these buffers are being filled...

EC2 volume ddata005.phacility.net filled up, causing problems for instances hosted on db005, leading to PHI771. I'll dig back into the CloudWatch monitoring stuff I setup a few months ago and make the db hosts report storage metrics the same way the repo hosts already do.

I'm going to look at improving the push logs a bit to show which rule blocked a push to address the actual use case in PHI765, which makes this more of a distance nice-to-have.

Pretty confident D19479 was the root cause here and we got unlucky (or lucky, to find the bug) by running with 37,000 commits exactly.

That went through totally clean.

I'm going to try truncate + rebuild and see if this is a first-run issue, maybe?

A sub-issue here is that rebuild-identities (and, likewise, CommitMessageParserWorker) uses getAuthorName() from the CommitData.

I did catch a rebuild-identities script eating 66% of CPU this morning, so I'm pretty sure there's a problem there somewhere, but it died at some point (likely when I restarted MySQL?) so there isn't much left in terms of forensic evidence.

My guess is that it's running in a loop and that I have a bug in PhabricatorQueryIterator.

This problem fixed by T13140. Thank you.

In D19455 I've reduced our "enormous change" threshold from 1GB to 256MB, which puts us underneath Git's 512MB magic number. This probably mitigates this to at least some degree.

Mercurial 4.6 has added hg help internals.bundle2 which will render a book to your console with details about the format/protocol. I did a high-speed skim and then tried out hg help internals.changegroup on a whim which produced an even longer book about the stream protocol (SSH only maybe?).

From PHI604, for completeness, on the newer behavior of "Hide Blame":

See T13125 for a more detailed breakout of coverage plans.

See T13125 for coverage plans.

@tycho.tatitscheff I have the same problem.
I tried to use /usr/bin/git-receive instead of /usr/lib/git-core/git-receive
Still the same.

This particular page here is fataling: