In D18181#240863, @epriestley wrote:

(Does this survive a cert file with no terminal newline?)

Ping on this?

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?

In T13053#235208, @epriestley wrote:

Hrrrm...

Ah! Yes, sorry for not using the right term.

Please commandeer -- I don't have a trivial way to test this at current.

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.

• Switch to --rev tip

Sorry for the breakage!

In D18606#227322, @epriestley wrote:

Cool, sounds like we're pretty much on the same page, then. Basically, I'm supportive of pursuing this but I'd rather do a "high workflow disruption, low cleverness" change than a "tons of cleverness so we don't have to change any behaviors" sort of change. I don't think the current behavior is sacrosanct and we can probably have a much larger impact by disrupting the current workflow a bit (or a lot).

Swap to a strlen, instead of using truthiness

In D18606#227169, @epriestley wrote:

P2074 is the change that builds on this one

Aaah, I misunderstood what you were trying to build here.

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'.

Do you mean "follow up in PHI55"?

@stefren should be covered by the #Dropbox corporate CLA.

We've also had a request for this (disabling the in-application popups) at #dropbox, as a per-user preference.

#dropbox has also encountered this since upgrading from MySQL 5.5 to MySQL 5.7, and thus an InnoDB FTS backend.

Beautiful. Sorry for not finding that.

Sorry, just pulling that out. 4d2c7e4d3d5d61e34b7e2af3df0e901d89d29433

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?

Aha! That works wonderfully. I think this is INVALID, then.

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.

T11997/T12032 look related, but not the same behavior.

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).

Based on two points of anecdata so far, things indeed seem snappier with D17959.

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.

Add some hopefully edifying comments

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.

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?