- User Since
- Aug 3 2015, 8:30 AM (142 w, 2 d)
Fri, Apr 20
Tue, Apr 17
Mon, Mar 26
Yeah, that's prbably exactly it -- we push staging refs to a different namespace to not clutter the standard tag namespace, which is likely the problem.
I'm getting permanent build failures on this diff, which look unrelated to the diff itself?
Feb 5 2018
Jan 24 2018
Ah! Yes, sorry for not using the right term.
Please commandeer -- I don't have a trivial way to test this at current.
Jan 6 2018
Jan 4 2018
This pain may be mostly derived from prior to D18842 and git performance improvements. At that time, delay until the prompt was ~4s, plus the overhead of noticing, pressing ^C, remembering command-line arguments to git clean, and the startup overhead of the arc diff startup again:
$ time arc diff --preview < /dev/null You have untracked files in this working copy.
The code currently shows:
Untracked changes in working copy: (To ignore this change, add it to ".git/info/exclude".) foo
...so remembering the path to edit isn't hard, as it's right there. The problem is more the immediacy -- it can be several minutes until one is back at a prompt to be able to run the hypothetical arc ignore, at which point we have the same problem we have now.
I think pressing ! accidentally is difficult -- it was chosen that way. We could bulletproof further via making it require typing I swear under penalty of perjury that I absolve arcanist from any and all fault when these files are removed at the prompt, but that might be a bit much.
Dec 24 2017
- Switch to --rev tip
Dec 23 2017
Dec 12 2017
Nov 22 2017
Sorry for the breakage!
Nov 16 2017
Sep 21 2017
Swap to a strlen, instead of using truthiness
Sep 20 2017
Sep 15 2017
Sep 14 2017
In the past, we ran lint and unit in the background while $EDITOR was open for the user to edit their commit message.
For context, the underlying goal of this change is to allow us to have Future versions of phutil_console_prompt and phutil_console_confirm which can operate while work is proceeding in the background. Our specific use case is to prompt "Unit tests are expected to take xxx seconds; run them locally?" while sneakily starting to run them in the background while the user is considering their answer. We abort the prompt future if the tests complete before we see a response from the user, and abort the test-running Futures if the user responds 'n'.
Sep 13 2017
Do you mean "follow up in PHI55"?
Aug 11 2017
Aug 4 2017
Jul 6 2017
@stefren should be covered by the #Dropbox corporate CLA.
Jul 5 2017
We've also had a request for this (disabling the in-application popups) at #dropbox, as a per-user preference.
Jul 4 2017
Jun 28 2017
#dropbox has also encountered this since upgrading from MySQL 5.5 to MySQL 5.7, and thus an InnoDB FTS backend.
Jun 12 2017
Beautiful. Sorry for not finding that.
Sorry, just pulling that out. 4d2c7e4d3d5d61e34b7e2af3df0e901d89d29433
Jun 7 2017
Noted, OK. We'll proceed by adding our own local ./bin/storage endpoint for it.
Would you be adverse to accepting a patch that does this?
Jun 2 2017
Aha! That works wonderfully. I think this is INVALID, then.
Jun 1 2017
Thanks for the fixes! Most folks are on Chrome at Dropbox, so Safari being subject to the Heisenprod Uncertainty Principle doesn't worry me much.
May 31 2017
May 30 2017
Forgot to specify browser: this is Chrome 58.0.3029.110 (64-bit) on OS X and Linux. Also replicates on Safari 10.1.1 (12603.2.4).
May 27 2017
Based on two points of anecdata so far, things indeed seem snappier with D17959.
May 26 2017
May 25 2017
Remove the equivalent codepath for Mercurial, which removed the
bookmark which we now never create at all. The entire original_branch
code is now unused, and this removed.
May 20 2017
Add some hopefully edifying comments
May 18 2017
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.
May 15 2017
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?
May 10 2017
May 6 2017
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.