I have a lot of functions that currently look like this:

function LoadFromURL(url) 
{
    var d = $.Deferred();
    $.get(url).then(function(text)
    {
        LoadFromText(text).then(function(obj)
        {
            d.resolve(obj);
        }, 
        function(err)
        {
            d.reject(err);
        });
    }, 
    function(err)
    {
        d.reject(err);
    });
    return d.promise();
}


This function takes a URL and loads the text within a promise. The text is then passed to the LoadFromText function which returns another promise. If this succeeds, the outer deferred is resolved. If the URL cannot be loaded, or the LoadFromText function fails then the outer deferred is rejected.

Is there a way that I can chain the result of the resolve / reject and end up with something like this:

function LoadFromURL(url) 
{
    return $.get(url).then(function(text)
    {
        return LoadFromText(text);
    }, 
    function(err)
    {
        return $.Deferred().reject(err);
    }).promise();
}


I've seen some implementations of promises that allow this - returning a promise within 'then', means that the eventual result of the promise is used. 

I realise this doesn't work at the moment (the result is the promise, rather than the result of the promise), but hopefully someone can suggest a way to make this work so I can tidy up the sometimes confusing mess of the first example.

I hope this makes sense. Thanks.


Question: How to avoid being asked passphrase each time I push to Bitbucket
Answer: For convenience, the optimal method is a combination of the answers of jmtd and Faheem.

Using ssh-agent alone means that a new instance of ssh-agent needs to be created for every new terminal you open. keychain when initialized will ask for the passphrase for the private key(s) and store it. That way your private key is password protected but you won't have to enter your password over and over again.

The Arch wiki recommends initializing keychain from /etc/profile.d/ or your shell profile, such as .bash_profile or .bashrc. This has a disadvantage in that it intializes your keychain as soon as you open a terminal.

A more flexible approach is to combine keychain with a specific tmux session. So, in .bash_profile:

tsess=$(tmux ls 2>&1)

if [[ "${tsess%%:*}" = "secured" ]] && 
   [[ -f $HOME/.keychain/$HOSTNAME-sh ]]; then
    # start keychain
    /usr/bin/keychain -Q -q --nogui ~/.ssh/id_rsa
    . $HOME/.keychain/$HOSTNAME-sh
fi

...and then it is just a case of starting the secured tmux session as and when required (launched from a keybind):

#!/bin/bash
PID=$(pgrep tmux)
new="tmux -f $HOME/.tmux/conf new -s secured"
old="tmux attach -t secured -d"

if [[ -z "$SSH_AUTH_SOCK" ]]; then
    eval `ssh-agent`
    trap "kill $SSH_AGENT_PID" 0
fi

if [[ -z "$PID" ]]; then
    urxvtc -title "SSH" -e sh -c "${new}"
else
    urxvtc -title "SSH" -e sh -c "${old}"
fi

ssh-add

Now, your keychain will only be initialized once when you start that specific tmux session. As long as that session persists, you will be able to access those ssh keys and push to your remote repositories.