Ben and Eliot, just in case you missed Jacobs answer to the git pull -a question (which you both seem to be confused about)
On Fri, 2 Jun 2017 at 10:00 Jakob Reschke jakob.reschke@student.hpi.de wrote:
2017-06-02 1:36 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
...
The commit is related to a graph of previous commits, right? So a branch implies a distinct set of commits, right? When one merges from a branch, the commits on the branch don't get added to the target into which one merges do they Isn't that the difference between pull and pull -a, that the former just pulls commits on a single branch while pull -a p;pulls commits on all branches?
Git commits refer to their parent commits (merge commits have more than one parent), but do not store on which branch(es) they are or were on. Since a branch is just a reference (to a commit), you may talk about the commits that are reachable from a branch (it is what you get from "git log branchname"). But this set almost always overlaps with that of other branches because of all the common ancestor commits.
Merging a branch adds an additional parent to the to-be-created merge commit. Thus, the commits from the merged branch become reachable from the branch into which you are merging. So, in a way, they do get added to the merge target.
pull -a does not "pull on all branches" and does not usually affect the result of the merge at all. "git pull <remote> <branch>" essentially means "git fetch <remote> <branch>", which writes the fetched commits to a temporary reference called FETCH_HEAD, followed by "git merge FETCH_HEAD". The -a stands for --append, is an option for the fetch, and means that instead of overwriting what is in .git/FETCH_HEAD, append the newly fetched commits there. But "git merge FETCH_HEAD" will only use the top commit from that file anyway, so this is kind of pointless for pull. In fact, it might lead to merging the wrong branch or not merging anything at all because the latest fetched commit with -a goes to the end of FETCH_HEAD, not the top.
But even if it meant to "pull commits on all branches", why would that be useful? When you work and pull on branch/feature X, why would you want to invoke a merge on an unrelated branch/feature Y?
If you wanted to merge more than one upstream branch into your current branch, you would have to name them all when pulling:
git pull origin branch1 branch2 ...
...which attempts a merge with (1 + number of unmerged upstream branches named on the command line) parent commits.