Part of this is likely a change to the semantics of setTimeout(). Current uses are:

• diffusion.blame, caller-specified
• diffusion.internalgitrawdiffquery, hard-coded at 30 seconds.
• DiffusionCommitHookEngine, hard-coded at 15 minutes ("enormous changes").
• DiffusionFileFutureQuery, ultimately caller-specified
• Meme transforms, hard-coded at 10 seconds.
• Thumb transforms, hard-coded at 60 seconds.
• PullLocalDaemon, the case in question, hard-coded at 15 minutes and 4 hours.
• Some stuff in test cases in libphutil.

For the ones that aren't caller-specified, I think we could pretty safely pick a min(timeout, 60) window between the TERM and the KILL.

I'm not exactly sure what we should do in the case of a very short caller-specified timeout.

• If the caller specifies a timeout of 3 seconds, when do we TERM/KILL?
• If they specify a timeout of 60 seconds, is it really OK to take up to 120 seconds to return?
• Generally, when they say "X", is it more important to try to return within X seconds or to let the command run for X seconds?

I'm inclined to say that the semantics of setTimeout(X) are "let the command run for X", and the actual time it takes the future to resolve is X + min(X, 60), i.e. up to twice as long. For example:

• If you set the timeout to 3, we TERM after 3 seconds and kill after 6 seconds. The command gets to run for 3 seconds but we may not return for 6.
• If you set the timeout to 60, we TERM after 60 seconds and kill after 120 seconds.
• If you set the timeout to 1234000, we TERM after 1234000 seconds and kill after 1234060 seconds.

There's always going to be call/command overhead anyway, so users shouldn't expect the behavior to be "return within X seconds" exactly anyway, although having 60 really mean up to 120 does feel a little weird. Maybe the magic number should be a bit shorter (like 15 or 30 seconds). But we should generally be hitting the timeout pretty much exactly anyway as long as subprocesses respond to TERM, which they almost always should.