- User Since
- Aug 3 2015, 8:30 AM (81 w, 4 d)
Thu, Feb 16
Yup, will try to get this upstreamed.
Non-backtracking forms of the two repetition characters.
Tue, Feb 14
Thu, Feb 9
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.
Aug 10 2016
Jul 12 2016
Use new libphutil functions.
Jul 11 2016
Feb 22 2016
Using SSH master connections has two advantages:
- Connections are indeed faster. In a minimal case (SSH'ing to an adjacent machine on the same network), it reduces the time for a no-op SSH connection from 0.14s to 0.01s. The utility of this grows as one needs to tunnel SSH connections in order to access a machine; for instance, SSH'ing to our Phabricator instance requires bouncing through a bastion host; using SSH master connections reduces the time to connect from ~0.7s to 0.01s. This is notable since arc may produce mulitiple git commands which attempt to fetch from upstream.
- Authentication information is preserved. If the connection does two-factor authentication, for instance, the user may be supplied with an authentication prompt when the master is set up. Re-using the master preserves this authenticated session, and reduces the amount of re-authorization that the user must do.
Nov 23 2015
Ack -- sorry for having forgot that fixup.
Nov 20 2015
Nov 6 2015
The problem was even though the upstream remote of the branch I was working on was in this arcanist, the remote named origin still pointed to our internal fork. Temporarily swapping the names of the upstreams around made it work.
Nope, no staging area:
$ arc diff HEAD~ Linting... LINT OKAY No lint problems. Running unit tests... PASS 16ms★ ArcanistLibraryTestCase::testLibraryMap PASS 9ms★ ArcanistLibraryTestCase::testEverythingImplemented PASS 36ms★ ArcanistLibraryTestCase::testMethodVisibility UNIT OKAY No unit test failures. SKIP STAGING Unable to determine repository for this change. Updated an existing Differential revision: Revision URI: https://secure.phabricator.com/D14420
Actual no-op diff
Just uploaded. Should I try again?
Landing via the UI failed with https://secure.phabricator.com/drydock/operation/58/ ; I'll use the CLI.
Nov 5 2015
Oct 31 2015
The URL to push to is constant. The ref to push to, however, would depend on what one was merging into -- hence what I mean by needing to be computed. Implementing this would also require replacing all of git-receive-pack on the server side; pushing into refs named by the server allows the server to not worry about magically hiding that overlap. As is, the server can manage the refs as normal refs, which works effectively.
How does removing the API call simplify matters? One still needs to have code to construct the name of the ref to push to (even if that's just a string concatenation). Doing that computation on a remote machine, rather than locally, makes little difference.
Hm, interesting. I see a few problems with that technique, though:
Oct 30 2015
Oct 28 2015
D14365, applied locally, does fix both issues.