You can, however, tell Git, at the time you create a branch, to set its upstream right then. If no upstream is set, VS apparently just runs git push origin newbr:newbr, rather than giving us an error. Visual Studio apparently behaves differently. The -u option to git push will then immediately set that as the upstream. A command-line git push will, with the defaults in modern Git, give us an error we will have to run git push -u origin newbr or git push -u origin HEAD to create a name newbr over on origin so that our Git will create origin/newbr locally, so that we have an origin/newbr to have as an upstream. When we use this form of branch creation, the new branch has no upstream set. That is, both branch names point to the same commit (whose hash ID is H). create the new name, pointing to the selected commit-in this case commit H-and then.When we ask Git to create a new branch name, with git checkout -b newbr in this case, Git will: (The real hash ID, in each case, is some big ugly random-looking string of letters and digits.) Commit G has a snapshot and metadata, and thereby points to still-earlier commit F, which has a snapshot and metadata, and so on. In this case commit H contains the hash ID of-i.e., "points to"-some earlier commit, whose hash ID we're just calling G. Every commit in Git has both a snapshot and metadata, and the metadata in a commit contain a list of previous commit hash IDs, usually just one entry long. That is, the name test points to some commit with some hash ID, drawn here as H, which stands for "hash". That's because the special name HEAD is attached to the branch name test, and the branch name test points to the commit whose hash ID both git rev-parse commands print. We will get the same hash ID from both operations. That is, if we have run git checkout test so that the current branch name is test, and we run: git rev-parse test The default hash ID, if we do not give Git one, is the hash ID of the current commit (as found by the current branch name in most cases). The newly created branch will point to this existing commit. Git needs the hash ID of some existing commit.Git needs the name of the new branch it should create.When we choose to create a new branch-with git branch, git checkout -b, or git switch -c-we must give Git two things:
#GIT SET UPSTREAM TO DIFFERENT BRANCH UPDATE#
The git push will this time call up origin and attempt to have the Git repository at origin update that other Git repository's branch br1 (the branch on the other Git that we remember, locally, as origin/br1). However, if we then run: git branch -set-upstream-to=origin/br1 We will get an error from git push because the name br2 in origin/br2 does not match the name br1. If we run: git branch -set-upstream-to=origin/br2 If this is set to simple-as it normally is today-this kind of git push will only push to the upstream of the current branch, and only if the upstream is set to a remote-tracking name that-once the remote part is removed-matches the current branch.įor example, suppose the current branch is named br1, and both origin/br1 and origin/br2 exist. In command line Git, the behavior git push, with no additional arguments, is controlled by the fault setting.
A branch either has an upstream set, or does not have an upstream set. That said, each branch, in Git, can have one upstream set. It's like assuming that a 1980s-era automobile has self-driving capability. It's important to know and understand this if you think that branches mean something in Git, you will eventually hurt yourself. Important backgroundīranches are not created from branches. Visual Studio apparently (mis)uses this to decide to ask the remote to update its test branch. It's because the upstream of your new branch is set to origin/test.
0 kommentar(er)
