bug - Inconsistency of git status and branch, ./git/branches and ./git/HEAD

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
1. create an empty directory in CLI: mkdir test_repo
2. convert it to a git directory: cd test_repo & git init
3. 'git status' will say you are "On branch master"
4. 'git branch', 'git branch --all', or 'git branch --list' - nothing
will say the master branch exists. And per man pages definition the
branch command displays existing branches. So the question is why 'git
status' says "On branch master", but 'git branches' don't?
5. check on 'ls -la ./git/branches' - it's empty
6. check on 'ls -la ./git/refs/heads' - it's empty
7. check on 'cat ./git/HEAD' - it shows 'ref: refs/heads/master' -
why? if we didn't create any commit, and no branch exists?

What did you expect to happen? (Expected behavior) git status should not say "On branch master", cat ./git/HEAD should be empty. Or the master branch should be created in ./git/branches and the 'git branch' command should display it.

What happened instead? (Actual behavior) Inconsistency between 'git status', 'git branch', ./git/branches and ./git/HEAD

What's different between what you expected and what actually happened?

Anything else you want to add:

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.41.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 6.4.12-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Aug 23 17:46:49 UTC 2023 x86_64 compiler info: gnuc: 13.1 libc info: glibc: 2.37 $SHELL (typically, interactive shell): /bin/bash

[Enabled Hooks]

apologies for a typo: all paths written with ./git, meant to be .git

On Sat, Sep 30, 2023 at 8:51 AM Irina Gulina <igulina@redhat.com> wrote:

Irina Gulina <igulina@redhat.com> writes:

Chris gave a good answer to this most relevant question; let me fill in one gap with others.

The directory is where you would configure how individual local branches you have would behave, and it is expected to be empty if you did not do anything special.

You can never expect the contents of .git/refs/* hierarchy to correspond to any state of the refs. If you have a history behind your local branch 'master', i.e., after running something like

    $ git init empty && cd empty && git commit --allow-empty -m init

you can "pack" the references, i.e.,

    $ git pack-refs --all

and all the necessary data for Git to know what your branches are and what commits they point at will be removed from .git/refs/* and stored in different place in .git/ hierarchy. So "there is no file at .git/refs/heads/master" does not mean "there is no master branch", even when we are not talking about a branch in the unborn state.

The same comment applies to the above. If you want to know the state of HEAD, there are commands to do so ("git branch --list" being one of them). Do not expect that .git/HEAD would stay forever be the implementation detail of what the HEAD ref points at.

On Sat, Sep 30, 2023 at 4:06 AM Irina Gulina <igulina@redhat.com> wrote:

Although this seems weird, it is in fact normal.

This situation in Git -- where you are on a branch that does not exist -- is called an "orphan branch" or an "unborn branch" (which term is used depends on which bit of documentation you read).

The unborn / orphan current branch becomes "born" (begins to exist) once you make a commit while on it. If you move to a different branch, the unborn branch never comes into existence.

A new, empty repository cannot have any branches, because a branch is defined as "the latest commit that is on the branch" (this definition is unsatisfyingly circular, but that too is what it is). With no commits in the repository, no branches can exist. Yet you must be "on" some branch. Hence the existence of unborn branches, which are born when you make a new commit. That first commit creates the first branch name as well as the first commit.

Creating a new commit while on an unborn branch causes the new commit to have no parent commit. This, too, is normal and natural in a new empty repository, but it holds true for the situation in which you create a new unborn / orphan branch using `git checkout --orphan` or `git switch --orphan` while in a non-empty repository. You don't normally want to do this, but it's sometimes useful for some special oddball cases.

Chris

I should note a slight correction here:

On Sat, Sep 30, 2023 at 4:28 AM Chris Torek <chris.torek@gmail.com> wrote:

This is just one of multiple definitions of "branch" in Git. A branch is also a *set* of commits, and/or a *name*. The fact that the word "branch" has so many meanings in Git makes it almost meaningless: it's like being at a party where everyone is named Chris. Yet somehow we humans still manage to extract meaning from a sentence like "Hey Chris, Chris said to tell you that Chris can't get Chris's car started, so Chris and Chris won't be here."

Chris