git merge origin - always defaults to tracking branch?

Question

Say I have a script that does something like:

git fetch origin

git branch | while read b; do
   git checkout $b
   git merge origin
done

my question is - will git always know what to do with the git merge origin command, assuming that all branches are tracked by the remote?

Answer 1

... will git always know what to do with the git merge origin command ...

Git will always do something . Probably not what you want, though! You probably want:

git checkout $b
git merge $b@{upstream}

which is not what will happen.

When Git is resolving a string like master or origin/develop or MERGE_HEAD to a commit hash ID, it follows the rules described in the gitrevisions documentation . In particular, there are six steps used. The first checks for a file in the .git directory. The third step checks for a tag name, and the fourth checks for a branch name.

Please follow the link above and examine each of the six steps listed under the SPECIFYING REVISIONS section, and think about what happens when Git tries origin at each step. For instance, at step 1, Git will check for a file named .git/origin , which (presumably) won't exist. Note that step 6, when applied to the literal string origin , checks for your refs/remotes/origin/HEAD . Now run:

$ git rev-parse refs/remotes/origin/HEAD

to see what hash ID you get. This tells you how git merge origin is going to behave.

(To see how to change the hash ID associated with refs/remotes/origin/HEAD , see the git remote documentation , particularly the set-head sub-command. But use the @{upstream} notation instead.)