- User Since
- Aug 3 2015, 8:30 AM (94 w, 1 d)
Sat, May 20
Add some hopefully edifying comments
Thu, May 18
My theory for not execPassthru was if it fails, those failures are likely irrelevant to the matter at hand (maybe they have an old, invalid, remote still hanging out), and spewing them to the console is just going to cause confusion.
Mon, May 15
Understood -- thanks for the clarification. One isn't always aware of how special-case one is. :)
Sorry, that seemed to be in response to "are you working on this?" A user has since provided a patch for the feature, which is the sort of thing which in the past you folks have generally been nice enough to review.
Phacility folks, do you have thoughts about the patch provided by @lyngvi above? Would be it be easier to review if submitted as a Diff?
Wed, May 10
Sat, May 6
Apr 20 2017
Apr 14 2017
Good to know. Thanks!
We're running 216f6be11ece53cb1daafc8fff636dbdb0d7ef3d, not the SHA given above.
Apr 4 2017
Mar 24 2017
Enabling that form seems to have done the trick -- thanks! Since it got renamed at some point from "Create form," its existence was almost certainly confusing to some previous admin, which is what got us into this.
I do now see that, but I'm unclear how to use its form to configure the form to configure the form to configure the form from.
Mar 23 2017
Mar 16 2017
Mar 6 2017
The table in the description references a getConduitFieldKey method – which I can't find reference to ever existing in the source. Was that supposed to be getFieldKeyForConduit?
Feb 16 2017
Yup, will try to get this upstreamed.
Non-backtracking forms of the two repetition characters.
Feb 14 2017
Feb 9 2017
Fix typo in comment
Jan 17 2017
Fixed by D17188.
Jan 12 2017
Rebase and re-run unit tests.
I think that's unrelated to this change, and purely based on the yacc version in the environment. Mind if I split that out into a separate diff?
Dec 21 2016
metamta.email-body-limit is unset.
Aha -- the diff as posted for review was mostly-reasonably sized. The diff as committed was the huge one:
mysql> select differential_diff.id as diff_id, creationMethod, SUM(addLines), SUM(delLines) -> from differential_changeset -> join differential_diff on differential_changeset.diffID = differential_diff.id -> where differential_diff.revisionID = 253041 -> group by differential_diff.id; +---------+----------------+---------------+---------------+ | diff_id | creationMethod | SUM(addLines) | SUM(delLines) | +---------+----------------+---------------+---------------+ | 837437 | arc | 11845 | 8567 | | 837558 | commit | 1752986 | 396108 | +---------+----------------+---------------+---------------+
bin/worker execute --id 35362582 did not work because the task was archived. Instead I ran ./bin/phd stop; ./bin/worker retry --id 35362582; ./bin/phd debug PhabricatorTaskmasterDaemon. The key seems to be the production of the .patch file itself, not the number of files. Somehow these users managed to cram a >100M patchfile into Differential:
Dec 20 2016
It will likely be easiest to replicate again after upgrading to Week 52 stable this Friday, since I can't use precise same diff, and don't know the precise set of replication criteria yet.
Dec 19 2016
Hm; we weren't running HEAD when we reported T11748. We have an upgrade planned to latest-stable in a week or so -- will that be sufficient to re-test with? Or is there a repository that we can apply a 4,800-file diff to on Phacility?
Nov 18 2016
This is a necessary, but not sufficient, step to be able to make the server better able to reason about stacked diffs. We use this as part of our CI integration, but it is currently used in the arc patch workflow as part of the message when the base commit is unavailable; it is used to suggest This diff is against commit D12345 rather than against commit 8badf00d.
Oct 14 2016
Sep 29 2016
Sep 21 2016
Somehow another change snuck in, though I don't see it locally?
Do normalization on checking in isRelevantMessage, not during
storage in paths.
That seems reasonable. I'll push an updated diff later today, which tries both forms of slashes in isRelemvantMessage() if running on Windows.
This is still logged as an EXCEPTION. Is DELETE FROM phabricator_repository.edge WHERE type = 39 a reasonable step to take, to prevent administrators unfamiliar with the non-fatal-ness of this from being worried?
Sep 20 2016
Aug 27 2016
This can cause a storm of commit mail when upgrading. If there are old tags which weren't imported at the time, when Phabricator is upgraded to a version containing D16129 it can fire off thousands of commit emails, flooding inboxes and making some folks grumpy at their Phabricator administrators.
Aug 19 2016
Aug 17 2016
Address review comments
Aug 16 2016
After further testing, this is only relevant now because git < 2.9 did not do rename detection by default; it was enabled in 2.9.