Why has Git allowed me to create two branches with the same name?

Question

I\'m still relatively new to Git and I have made a bit of a mess of my repository. I\'m hoping there is a way to fix it without re-cloning.

I have a repository whic

Answer 1

The true story is that Git has a simplification scheme for its "refs" (a Git lingo for "references", which is the term used to refer to branches, tags etc). In fact, references live in their namespaces, which, with the reference Git implementation, are just directories under .git. For instance, your local branch "master" is really "refs/heads/master" — a file named "master" located in the .git/refs/heads directory. There are also "refs/tags" namespace and "refs/remotes" namespace — for tags and remote branches (those created by the git fetch command).

Now when you tell Git to create a branch remotes/origin/abc it really creates refs/heads/remotes/origin/abc which does not clash with refs/remotes/origin/abc because the rules to deal with that simplification scheme make the former trump the latter. At any time you can use the full form of ref naming to remove any disambiguation.

The gory detals of how Git interprets ref names are described in the section "Specifying Revisions" of the git-rev-parse manual:

, e.g. master, heads/master, refs/heads/master

A symbolic ref name. E.g. master typically means the commit object referenced by refs/heads/master. If you happen to have both heads/master and tags/master, you can explicitly say heads/master to tell git which one you mean. When ambiguous, a is disambiguated by taking the first match in the following rules:

If $GIT_DIR/ exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD);

otherwise, refs/ if it exists;

otherwise, refs/tags/ if it exists;

otherwise, refs/heads/ if it exists;

otherwise, refs/remotes/ if it exists;

otherwise, refs/remotes//HEAD if it exists.

…