2017-06-02 1:36 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Thu, Jun 1, 2017 at 10:40 AM, Ben Coman btc@openinworld.com wrote:
I just want to interject a check everyone's understanding of git branches. Although I haven't used SVN, what I've read indicates SVN concepts can be hard to shake and git branching is conceptually very different from SVN.
The key thing is "a branch in Git is simply a lightweight movable pointer to a commit." The following article seems particularly useful to help frame our discussion... https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is
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.
vm-dev@lists.squeakfoundation.org