5

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

Tim
  • 597
  • 1
  • 5
  • 15
  • 1
    Can you post the command and the error message? a `git checkout tim --`, for instance, might work. – VonC Aug 21 '12 at 06:37
  • The commands and error are quite common. See S.O question: http://stackoverflow.com/questions/2527355/using-the-slash-character-in-git-branch-name or this external mailing site's thread: http://osdir.com/ml/git/2009-11/msg01037.html – Tim Aug 21 '12 at 06:58
  • That would only happen if you use a slash in the name of your branch. But a branch named '`tim`' alone should work. Again, what is the exact command you are typing, and what is its error message? – VonC Aug 21 '12 at 07:04
  • 1
    beside that, calling things the same name might confuse not only Git ... naming is never obvious but giving different names is not that a big effort (like `timbranch`, as you suggested yourself) – Vince Aug 21 '12 at 07:09
  • I don't have the exact commands, nor the exact error message any more, nor any accessibility to generating them. But they were similar to the same as the previous S.O I linked to earlier. I had deleted my local "tim" branch refs, created a folder called "tim" and then made a new branch called "tim" inside and pushed it. Others trying to fetch from the repo had the old "tim" branch and therefore it couldn't create the remote ref. – Tim Aug 21 '12 at 07:10
  • True, it's not much effort giving it a different name, but why is it confused between a branch and a folder? It should be perfectly fine with it. In other words, this question is about if there's a reason it has be worked around in the first place? – Tim Aug 21 '12 at 07:16

2 Answers2

5

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.
Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
  • Exactly the response I was looking for. A pack 'n' prune may fix the issue too I suppose. – Tim Aug 21 '12 at 07:57
0

Git can have difficulties when you try to convert a file name tim (which stores the branch head) to a directory name tim/ (when you have slashes) because of the naming freedoms for references (see git-check-ref-format).

Philip Oakley
  • 13,333
  • 9
  • 48
  • 71
  • Correct. I stated I already knew this in the description/backstory of the question, but it was not the actual question itself. The question was WHY this is enforced. Why not store the branch ref files with an extension to stop this difficulty? – Tim Aug 22 '12 at 00:05
  • @Tim, Essentially, as far as I can tell, 'extensions' are a Windows thing, while 'Git' is a unixy thing. So apart from those `check-ref-format` rules they allow any character sequence (no special 'extension' rules) for the file and directory names, as is normal unix practice, so there was no possibility of an extension rule to be enforced. IIUC the 'gotcha' [corner case] you hit was was changing from `tim` to `tim` `/` which probably wouldn't have occurred if the new grouping had a different name, e.g. `timsBranches/` – Philip Oakley Aug 22 '12 at 07:09
  • @Tim, Di you use a git command to rename the `tim` branch, or did you simply move the file to a subdirectory and then get the error message(s)? – Philip Oakley Aug 22 '12 at 12:12
  • Hence the previous/accepted answer: "In unix one does not normally use file extensions, so there were none". I deleted my branch ref and used a git command to make `tim/tim`. – Tim Aug 23 '12 at 08:50
  • Also file extensions aren't a Windows thing. Other operating systems use file extensions heavily. Even though git is traditionally run through a CLI, I still do think they could simply support extensions on files. It gets around this exact problem. But oh well, their choice. – Tim Aug 23 '12 at 08:51