Comment 11 for bug 172392

bug 40508 and bug 5987 are the history for why ssh is handled this way.

When bzr gets a ^c, we don't want to have that signal sent to the ssh subprocess too, because bzr may want to do some cleanup before it exits, such as releasing a lock (assuming the connection is still working at all). We don't want to revert that change.

You could argue that we should always just immediately stop, without attempting any cleanup, though this will cause some leftover temporary files, broken locks, etc. But they should be recoverable. Doing cleanup across the network may anyhow be slow and/or unreliable.

We could do one of these:

1- keep a list of ssh subprocesses, and when exiting the bzr process (atexit) send sighup to all of them
2- when closing the remote medium, wait a short time for ssh to exit, then send sighup to it