A caution about git branch names with '/'s
I recently learned, from a comment by @richoh on a post of mine (http://coderwall.com/p/-kh5bq?i=1&p=1&q=&t%5B%5D=%21%21mine&t%5B%5D=%21%21bookmarks) about a convention for using branch names beginning with 'wip/' for "works-in-progress", i.e. branches where I need not be terribly careful that my commits break the build or introduce regressions.
I soon ran into trouble creating branch names with multiple '/'s in them, however, due to the following:
Let's say I first create a branch named 'wip/foo':
git branch wip/fooGit will create a file named 'foo' in the folder .git/refs/head/wip/. Now, suppose I attempt to create a new branch named 'wip/foo/foo-offshoot'. git will return an error:
error: unable to create directory for .git/refs/heads/wip/foo/foo-offshoot
fatal: Failed to lock ref for update: No such file or directoryInvestigation of this answer, http://stackoverflow.com/a/2527452/1286986, led me to understand that 'foo' is a file, whereas the branch name up to the preceding slashes will be used as a folder. When I attempt to create the second branch, it attempts to now create '.git/refs/heads/wip/foo/' as a folder, but it cannot, because it already exists as a file! A comment by Slipp D. Thompson under this answer at stackoverflow, http://stackoverflow.com/a/6065944/1286986, suggests some interesting workarounds, one of which is to use a pre-decided default suffix to name the branch file, such as 'main' in 'wip/foo/main' and 'wip/foo/foo-offshoot/main'.
Written by Anthony Hall
Related protips
3 Responses
I have been bitten by this, too. It's a good case for learning how the Git plumbing works.
Oh, sorry maybe I didn't explain well enough.
It's also worth noting that if you do something like:
git co -b wip/foo
# hack hack hack
git push -u origin wip/foo
# Oh, shit I'm going to make a few passes at this
git push origin :wip/foo
git branch -M wip/foo/stuff
git push -u origin wip/foo/stuffEverything will look sane to you, but it'll explode on anyone who fetched the old ref and they'll need to git remote prune. Basically, unless you're in a position to go around to everyone, it's more antisocial than rebasing public commits.
Hope this helps.
Thanks, ran into this exact issue because some developers use GNU/Linux (ext3 or ext4), where filenames are NOT case-sensitive, and I use Mac OS X, where filenames ARE case-sensitive. Thus, only OS X users were getting the git error. But once it happens you cannot push any code at all, no matter what branch you're in until it is fixed remotely.
In other words, you could have wip/FOO and wip/foo/bar exist perfectly fine on an ext3/4 Linux system, because FOO is a file and "foo" is a folder, but it would break on mac os x.
