Re: bug: git branch -d and case-insensitive file-systems
On Mon, Aug 24, 2015 at 12:11:13PM -0400, Aaron Dufour wrote:
Show 20 quoted lines
> 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).
In the meantime, I think the best advice for mixed-case branch names on
a case-insensitive filesystem is: don't.
-Peff
