Irina Gulina <igulina@xxxxxxxxxx> 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.
