#GIT LIST BRANCHES COMMAND FULL#
Using git checkout -orphan leaves the index undisturbed, which is why I ran git status | head -3 above: the index is still full of all the files from the tip of master, in my case: $ git status -short -branch | head -5 When you are in this peculiar state of being on a branch that does not exist, this has an important effect on the next git commit that you run.Īs always, git commit will build its new commit's content from whatever is in the index at the time you run git commit. When in orphaned state, the next commit will be a root commit Otherwise, you'll get the branch name: $ git symbolic-ref HEADĮven if the branch name does not exist. If you're in detached HEAD state, the command will fail (with an error message), so you know that HEAD is not attached to any branch name. To see which branch name HEAD is attached to, use git symbolic-ref HEAD. Git currently says no, but maybe someday the Git authors will change their minds.) ( Should git branch enumerate this extra, nonexistent branch? That's a reasonable question to ask. The git branch command enumerates the branches that exist, so it skips over this unborn branch, if you're in this peculiar state. That branch does not have to exist! If it does not, Git says that you are on an unborn branch, or sometimes that you have an orphan branch, or just a branch with "no commits yet". That is, HEAD contains the name of a branch. HEAD is normally a symbolic reference (except, of course, when it's "detached"). This paradox arises because a symbolic reference can name a branch that does not exist. Therefore the branch master cannot exist. In a new, empty repository, there are no valid commits. A branch exists because a reference whose name starts with refs/heads/ contains the hash ID of a valid commit. In a new, empty repository just created by git init, that is always the case. What's going on here is that you can be on a branch that does not exist.
#GIT LIST BRANCHES COMMAND UPDATE#
(use "git pull" to update your local branch) Your branch is behind 'origin/master' by 98 commits, and can be fast-forwarded. You can achieve this same state any time you like, in any other Git repository, using git checkout -orphan: $ git status I would not, however, call it an invalid state. Of course git show will then show you the HEAD commit of this branch, and no error message, and git branch will report no evidence of the master branch, either.Īs Sam Varshavchik answered, you're in a peculiar state.
If you do a git checkout mongodbutils, all traces of the master branch will be gone. What you're seeing, with that error message, is the end result of git's current, temporary, confused state.
This happens with every commit, not just the initial commit, but now, after the initial commit, everything is in order. Once a first commit is made, the commit gets pushed into the repository, and the git branch gets repointed to the commit in question. A git init initializes the repository with the HEAD indicating that it's the HEAD of a master branch, but there is no actual master branch in the repository. A branch is just an alias for one of the commits in the repository. The HEAD is set to point to the master branch, but the master branch does not exist in the repository itself.Ī git branch is synonymous with the commit at the HEAD of the branch. In a freshly-created git repository, until something gets pushed onto the master branch the repository is actually in a slightly "invalid" state.
0 kommentar(er)
