Jeff King <peff@xxxxxxxx> writes: > For example, imagine repo1 has two branches, "master" and "foo", and the > "master" branch is checked out. When you clone it, the resulting repo2 > will have remote-tracking branches for both "master" and "foo", but will > only checkout the "master" branch. Now imagine you make commits on > "foo" in repo1, and then try to push. Git's default behavior is to push > only branches which match (by name) a branch on the destination. So we > would attempt to push "master" (which is up to date), but not "foo". Technically you are not saying anything incorrect, but the above is not an appropriate paragraph to give to a total newbie, I would have to say. It does not make it clear that it is insane to push to repo2 with matching push (or "current" or "upstream" for that matter), after cloning from a repository repo1 with a working tree to repo2 with an working tree, and making changes at the original repo1 repository. Instead, you are giving a false impression that pushing both "master" and "foo" explicitly would solve the problem OP is having, which is not true. If repo1 and repo2 with working trees want to criss-cross-exchange their histories, both should "git pull" from the other, not "git push", and if one side cannot initiate a connection to the other, "git push" that goes in the other direction should be pushing into remote tracking refs of the other in order to emulate a "git pull" that goes in the other direction. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html