Fwd: bug: git branch -d and case-insensitive file-systems

On Mon, Aug 24, 2015 at 12:11:13PM -0400, Aaron Dufour wrote:

quoted

I use git (2.2.1) on OS X (10.9.5) and recently my repo got into a bad
state.  I think this involves a mis-handling of case-insensitive file
systems.

This reproduces the problem:

    > git init
    Initialized empty Git repository in /Users/aarond_local/code/git-test/.git/
    > git commit --allow-empty -m 'first commit'
    [master (root-commit) 923d8b8] first commit
    > git checkout -b feature
    Switched to a new branch 'feature'
    > git checkout -b Feature
    fatal: A branch named 'Feature' already exists.
    > git checkout -B Feature
    Switched to and reset branch 'Feature'
    > git branch -d feature
    Deleted branch feature (was 923d8b8).
    > git log
    fatal: bad default revision 'HEAD'

I don't work on a case-insensitive filesystem, so my knowledge may be
out of date, but as far as I know, we do not do anything special to
handle ref case-sensitivity. I expect your problem would go away with
this patch:

diff --git a/builtin/branch.c b/builtin/branch.c
index 58aa84f..c5545de 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c

@@ -19,6 +19,7 @@
 #include "column.h"
 #include "utf8.h"
 #include "wt-status.h"
+#include "dir.h"

 static const char * const builtin_branch_usage[] = {
        N_("git branch [<options>] [-r | -a] [--merged | --no-merged]"),

@@ -223,7 +224,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
                int flags = 0;

                strbuf_branchname(&bname, argv[i]);
-               if (kinds == REF_LOCAL_BRANCH && !strcmp(head, bname.buf)) {
+               if (kinds == REF_LOCAL_BRANCH && !strcmp_icase(head, bname.buf)) {
                        error(_("Cannot delete the branch '%s' "
                              "which you are currently on."), bname.buf);
                        ret = 1;

but I think that is just the tip of the iceberg. E.g. (on a vfat
filesystem I just created):

  $ git init
  $ git commit -q --allow-empty -m one
  $ git branch foo
  $ git branch FOO
  fatal: A branch named 'FOO' already exists.

  $ git pack-refs --all --prune ;# usually run as part of git-gc
  $ git commit -q --allow-empty -m two
  $ git branch FOO
  $ git for-each-ref --format='%(refname) %(subject)'
  refs/heads/FOO two
  refs/heads/foo one
  refs/heads/master two

Now the patch I showed above would do the wrong thing. Running "git
checkout foo; git branch -d FOO" would be rejected, even though I really
do have two separate branches.

It would be a much more invasive change to fix this correctly. It is
probably less work overall to move to a pluggable ref system, and to
design ref storage that isn't dependent on the filesystem (this work is
already underway).