git push unexpected behavior with 2 remotes

Related searches

I have the following setup:


origin, vijay

local branches:

  • master
  • 14.4_dev (created by doing git checkout origin/14.4_dev -b 14.4_dev)
  • 14.4_various_features (created by doing checkout vijay/14.4_various_features -b 14.4_various_features)

When I am on the 14.4_various_features branch and do git push, it pushes my local branches (such as master and 14.4_dev) into the vijay remote. Is this expected behavior?

Git - Pushing code to two remotes, In recent versions of Git you can add multiple pushurl s for a given remote. Use the following to add two pushurl s to your origin : git remote� To see which remote servers you have configured, you can run the git remote command. It lists the shortnames of each remote handle you’ve specified. If you’ve cloned your repository, you should at least see origin — that is the default name Git gives to the server you cloned from:

In your .git/config file you can choose which one is the default remote for each branch. At this point, it probably says

[branch "master"]
        remote = vijay
        merge = refs/heads/master
[branch "14.4_various_features"]
        remote = vijay
        merge = refs/heads/14.4_various_features
[branch "14.4_dev"]
        remote = origin
        merge = refs/heads/14.4_dev

Depending on your global git push strategy, your pushes might do what you're describing. Unless your strategy is set to 'current' git will iterate over your branches pushing each one of them to their matching branch in their respective remotes.

Unclear error message when remote rejects push � Issue , Description GitHub Desktop gives the whole git log when trying to push to a Expected behavior: A better error message, at least without all the git log when it push origin master:master --progress` exited with an unexpected code: 1. (2/ 2), completed with 2 local objects. remote: error: GH006: Protected� Push identical code into two git remote repositories We have configured a project in IntelliJ as well as a remote Git repository, where we maintain the project - we commit and push our code to that repository.

Handling Git Push Problems, Merge the remote changes (e.g. 'git pull') before pushing again. Try #2. $ git pull Already up-to-date. $ git status # On branch of how git push/pull work, combined with the poorly chosen default behavior of git push The root cause of the problem is the unexpected asymmetry of git pull and git push . Notice how git push is essentially the same as running git merge master from inside the remote repository. Git push and syncing git push is one component of many used in the overall Git "syncing" process. The syncing commands operate on remote branches which are configured using the git remote command. git push can be considered and 'upload

The Dark Side of the Force Push, When you push changes to a remote server, Git prevents you from pushing your changes if the In Git 2.0, this behavior was changed to only push the current branch, but older versions still have this unexpected behavior. Git - Push the code on two remotes This question already has an answer here: pull/push from multiple remote locations 12 answers I have two remote git repositories. origin and github I push my branch devel to both repositories. git push -u origin devel git push -u github devel But the

Working with Remotes, git clone Cloning into 'ticgit' remote: Reusing existing For example, a repository with multiple remotes for working with several If you want the default behavior of git (fast-forward if possible, else create a� The git remote command is one piece of the broader system which is responsible for syncing changes. Records registered through the git remote command are used in conjunction with the git fetch, git push, and git pull commands. These commands all have their own syncing responsibilities which can be explored on the corresponding links. Git remote

If in doubt about what git is doing when you run these commands, just edit .git/config (git-config(1)) and see what it's put there. Remotes Suppose your git remotes are set up like this:

  • thanks for this. It was indeed matching. I don't mind this behavior as long as I know what it is doing now.