Hacker News Reader

Comment by 015a | Hacker News Reader

One interesting, slightly related thing about git branching I run into every once in a while:

   $ git checkout -b test
   Switched to a new branch 'test'
   $ git checkout -b test/1
   fatal: cannot lock ref 'refs/heads/test/1': 'refs/heads/test' exists; cannot create 'refs/heads/test/1'

Forward slashes are special in branch names; I'd guess because there's a filesystem representation of the branch name happening in there.

View on HN

>I'd guess because there's a filesystem representation of the branch name happening in there.

Yep, it works exactly how you're assuming. You're asking the filesystem to create a directory with the same name as an existing file.

Por exemplo:

    ls .git/refs/heads
    cat .git/refs/heads/master

Interestingly, this prefix rule which is based on the filesystem-based ref storage is enforced even if refs are stored via alternative means like .git/packed-refs, since the refs could later be stored in the filesystem. You can verify this by calling `git pack-refs --all` and verifying that your .git/refs/heads directory is empty but you still cannot create conflicting branches.

Is this on Windows? Or maybe you're on an older version of Git? I make branches with slashes in the name all the time, never had a problem with it.

The parent comment is specifically referring to creating a new branch from an existing branch with a slash in the name (ex: 'test-branch' and 'test-branch/new'). Trying it on my own machine (macos) yields an error. Even switching branches first and creating the new one yields an error.

You should find that vice versa also errors. After all, in principle I guess it's possible to store data in a directory (it looks like EXT2 in particular would let you store data in between entries, https://tldp.org/LDP/tlk/fs/filesystem.html#ext2fs-dir-figur... ), but the natural law is that a directory can't contain file contents.

First ran into this on persistent servers, where the deployed instance knew branch names github had long forgotten about.. Someone pushed a branch named "bugfix", and `git fetch` started erroring.

You get even _more_ interesting problems if part of your team has case-insensitive file-systems!

The version I have installed is a year old (2.39 is from last year) and this is a Mac rather than windows...

    % git init
    Initialized empty Git repository in /private/tmp/gittest/.git/
    % git commit --allow-empty -m "initial"
    [main (root-commit) fa2cf4e] initial
    % git checkout -b test
    Switched to a new branch 'test'
    % git checkout -b test/1
    fatal: cannot lock ref 'refs/heads/test/1': 'refs/heads/test' exists; cannot create 'refs/heads/test/1'
    % git --version
    git version 2.39.3 (Apple Git-145)
    % git checkout -b foo/bar
    Switched to a new branch 'foo/bar'
    % git checkout -b foo/qux
    Switched to a new branch 'foo/qux'
    % git checkout -b foo
    fatal: cannot lock ref 'refs/heads/foo':     'refs/heads/foo/bar' exists; cannot create 'refs/heads/foo'

The issue is that 'test' exists before 'test/1' was (attempted to be) created.

    % pwd          
    /tmp/gittest/.git/refs/heads
    % find . -print
    .
    ./test
    ./foo
    ./foo/qux
    ./foo/bar
    ./main
    % file *
    foo:  directory
    main: ASCII text
    test: ASCII text

In refs/heads, 'test' is a file and thus git is unable to create 'test/1'.

https://stackoverflow.com/a/2527452/2788187

Reply on news.ycombinator.com