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

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

[Irina Gulina]

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]

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

[Irina Gulina]

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:
>
> 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]

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

[Junio C Hamano]

Irina Gulina <igulina@redhat.com> writes:

>> 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?

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

>> 5. check on 'ls -la ./git/branches' - it's empty

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.

>> 6. check on 'ls -la ./git/refs/heads' - it's empty

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.

>> 7. check on 'cat ./git/HEAD' - it shows 'ref: refs/heads/master' -
>> why? if we didn't create any commit, and no branch exists?

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.

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

[Chris Torek]

On Sat, Sep 30, 2023 at 4:06 AM Irina Gulina <igulina@redhat.com> wrote:
> ... So the question is why 'git
> status' says "On branch master", but 'git branches' don't?

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

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

[Chris Torek]

I should note a slight correction here:

On Sat, Sep 30, 2023 at 4:28 AM Chris Torek <chris.torek@gmail.com> wrote:
> 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).

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