Why don't Git refs have a file extension

Question

I had recently stumbled upon a common problem in Git when creating branch groups:

I had a branch called "tim".
I wanted to make a folder/group called "tim", with the "tim" branch inside it, resulting in the branch path being "tim/tim".

When I tried to do this, Git really hated me because the folder "tim" and the branch ref "tim" were the exact same thing according to Git.

My question, is if anyone knows why does a branch ref not have an extension of some sort to get around this issue? Say .gitbranch or whatever?
Obviously it'd be a little more work to append on .gitbranch whenever accessing the file, but barely anything compared to the work the user has to do to get around this issue, especially when you're in a development team. (Anyone who had previously cloned the repo had to then manually go into their refs folder and remove any trace of branches named "tim", otherwise they couldn't fetch!)

If this actually a legitimate issue, I will raise it with the appropriate channels, but I wanted to check if anyone could possibly know why they could have possibly done this purposefully?

Thanks all,
Tim

Answer 1

I don't think there is any particular rationale either way. In unix one does not normally use file extensions, so there were none. That meant you can't have a foo and foo/anything at the same time. That was documented and is now cast in stone and won't change, though the remote references are usually stored in the packed format all in one file these days.

However:

• git fetch should be smart enough to prune the old branch before creating the new one if given the -p (--prune) option is given. If it does not, you should definitely bring it up on git mailing list.
• I only see a way to default prune in gui, but not in the fetch config for the remote. It would make sense to ask about that as well.