Unfortunately, whether they are equivalent or not in general depends on which branch you are on, your configuration, phase of the moon, etc.
You can figure this out from the git pull man page, as I've described below, but I would generally try to avoid having to work that out by doing: git fetch origin and then git merge origin/foo. (I wrote a somewhat rambling blog post about this.)
However, your question is really about the default behaviour of git pull when you don't specify a remote or a refspec. We can figure this out from the git pull man page, and in particular the DEFAULT BEHAVIOUR section. This is somewhat tough to figure out, so I've put in bold the only parts that really apply to your question given that (a) you are on branch foo, (b) you created that branch as you described in the question, and (c) you haven't been changing your configuration.
Often people use git pull without giving any parameter. Traditionally, this has been equivalent to saying git pull origin. However, when configuration branch.<name>.remote is present while on branch <name>, that value is used instead of origin.
In order to determine what URL to use to fetch from, the value of the configuration remote.<origin>.url is consulted and if there is not any such variable, the value on URL: line in $GIT_DIR/remotes/<origin> file is used.
In order to determine what remote branches to fetch (and optionally store in the remote-tracking branches) when the command is run without any refspec parameters on the command line, values of the configuration variable remote.<origin>.fetch are consulted, and if there aren’t any, $GIT_DIR/remotes/<origin> file is consulted and its Pull: lines are used. In addition to the refspec formats described in the OPTIONS section, you can have a globbing refspec that looks like this:
refs/heads/*:refs/remotes/origin/*
A globbing refspec must have a non-empty RHS (i.e. must store what were fetched in remote-tracking branches), and its LHS and RHS must end with /*. The above specifies that all remote branches are tracked using remote-tracking branches in refs/remotes/origin/ hierarchy under the same name.
The rule to determine which remote branch to merge after fetching is a bit involved, in order not to break backward compatibility.
If explicit refspecs were given on the command line of git pull, they are all merged.
When no refspec was given on the command line, then git pull uses the refspec from the configuration or $GIT_DIR/remotes/<origin>. In such cases, the following rules apply:
If branch.<name>.merge configuration for the current branch exists, that is the name of the branch at the remote site that is merged.
If the refspec is a globbing one, nothing is merged.
Otherwise the remote branch of the first refspec is merged.
When you created the branch foo with:
git checkout origin/foo -b foo --track
... it will have set the following config options, which associate your branch foo with refs/heads/foo in the origin repository:
branch.foo.remote=origin
branch.foo.merge=refs/heads/foo
So, if you put that together with the emboldened sentences above, the answer is "Yes, in this situation you describe, when you're on branch foo, the commands git pull and git pull origin foo are equivalent."
A git pull does a fetch followed by a merge, and you can't merge without a working tree. (There would be nowhere to resolve merge conflicts if they should arise.)
Instead, you could just fetch. Assuming your main repository is configured as a remote called origin on your personal repository:
$ git fetch origin master:master
Note that this will only be successful if the master branch of your personal repository is mirroring the master branch of the main repository. Otherwise, Git will reject the non-fast-forward fetch.
Best Answer
Try