git log and show on a bare repo

by

Yes, this is normal for new bare (and non-bare) repositories.

Explanation

HEAD is what Git calls a symbolic reference—a reference to another reference.

In non-bare repositories, HEAD normally indicates which branch is currently checked out. A new commit will cause the branch named by HEAD to be advanced to refer to the new commit. When HEAD refers to a commit object directly instead of a branch, it’s considered to be detached, meaning further commits will not cause a branch reference to be advanced to refer to the new commits (dangerous because checking out a different commit or branch will render the new commits unreachable by any existing reference, making them hard to find and subject to garbage collection).

In bare repositories, HEAD indicates the repository’s default branch, so that in a clone of the repository git checkout origin is equivalent to git checkout origin/master if master is the default branch (see git help rev-parse for details).

When Git initializes a new repository, it initializes HEAD to refer to refs/heads/master (in other words, HEAD points to the master branch by default). However, it does not create a branch named master because there are no commits in the repository for master to point to yet.

So until you either create a master branch or change HEAD to point to a branch that does exist, you’ll get that error when you run a command that looks at HEAD (such as git log or git show without any arguments).

You can still use commands that don’t examine HEAD. For example:

git log some_branch_that_exists

Fix

To get rid of the error message, you can do one of the following:

  • Change HEAD to point to a branch that does exist:

    git symbolic-ref HEAD refs/heads/some_other_branch
  • Push a new master branch into the repository from somewhere else

  • Create a new master branch locally:

    git branch master some_existing_commit

Visualization

To visualize everything in the repository, I use something like this:

git log --graph --oneline --date-order --decorate --color --all

Note that the above command will work even if HEAD is pointing to a non-existent branch.

More Related Contents:

  1. Git push requires username and password
  2. Git workflow and rebase vs merge questions
  3. What is the difference between origin and upstream on GitHub?
  4. Deleting a badly named git branch
  5. What does the term “porcelain” mean in Git?
  6. How can I automatically push after committing in Git?
  7. Git SSH authentication
  8. .gitignore and “The following untracked working tree files would be overwritten by checkout”
  9. How to git-cherry-pick only changes to certain files?
  10. What is the best practice for dealing with passwords in git repositories?
  11. How can sbt pull dependency artifacts from git?
  12. Setting up and using Meld as your git difftool and mergetool
  13. How do you use “git –bare init” repository?
  14. Git pre-push hooks
  15. Who is “us” and who is “them” according to Git?
  16. heroku: src refspec master does not match any
  17. Git: can I suppress listing of ‘modified content’/dirty submodule entries in status, diff, etc?
  18. Checkout multiple git repos into same Jenkins workspace
  19. Moving a git repository up one hierarchy level
  20. Difference between different git search commands
  21. Collapsing a git repository’s history
  22. How can I push my existing Git repository to Team Foundation Service
  23. How to colorify git errors, warnings and fatal messages?
  24. How can I move all git content one-level up in the folder hierarchy?
  25. How do I make git merge’s default be –no-ff –no-commit?
  26. Git: How to make outer repository and embedded repository work as common/standalone repository?
  27. Why do excluded files keep reappearing in my git sparse checkout?
  28. How to quit (not abort) a Git merge in progress keeping the changes uncommitted?
  29. How to push different local Git branches to Heroku/master
  30. SSH Agent Forwarding with Ansible

Leave a Comment