# bug: git branch -d and case-insensitive file-systems 3 messages from 2015-08-24 to 2015-08-25. Participants: Aaron Dufour, Jeff King. Thread: https://gitlist.dev/t/40167 ## Aaron Dufour, 2015-08-24 16:11 Subject: bug: git branch -d and case-insensitive file-systems Message-ID: URL: https://gitlist.dev/e/CAJrRhQz1UmnDi6Giejetfoh3aPX08aYcgY-neZfcKjpUav0%3DsA%40mail.gmail.com ``` 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' This is the behavior when there isn't a case mismatch, which is what I would have expected in the previous case as well: > git init Initialized empty Git repository in /Users/aarond_local/code/git-test/.git/ > git commit --allow-empty -m 'first commit' [master (root-commit) 48df19f] first commit > git checkout -b feature Switched to a new branch 'feature' > git branch -d feature error: Cannot delete the branch 'feature' which you are currently on. I can also reproduce the issue on git 2.5.0. -Aaron Dufour ``` ## Jeff King, 2015-08-25 05:21 Subject: Re: bug: git branch -d and case-insensitive file-systems Message-ID: <20150825052123.GA523@sigill.intra.peff.net> URL: https://gitlist.dev/e/20150825052123.GA523%40sigill.intra.peff.net In-Reply-To: ``` On Mon, Aug 24, 2015 at 12:11:13PM -0400, Aaron Dufour wrote: > 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 [] [-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 ``` ## Aaron Dufour, 2015-08-25 15:42 Subject: Fwd: bug: git branch -d and case-insensitive file-systems Message-ID: URL: https://gitlist.dev/e/CAJrRhQyiiAQi6RqHJcVFn7%3DjBfxNvpp_mbOXTsAWHQMWc6gcuQ%40mail.gmail.com In-Reply-To: ``` On Tue, Aug 25, 2015 at 1:21 AM, Jeff King wrote: > On Mon, Aug 24, 2015 at 12:11:13PM -0400, Aaron Dufour wrote: > >> 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 [] [-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). That's great news! > > In the meantime, I think the best advice for mixed-case branch names on > a case-insensitive filesystem is: don't. Yeah, that's definitely the solution. I got into a weird place because our build system uses branch names, but it restricts them to lowercase letters and I made the mistake of camel-casing. I'll just be more careful. > > -Peff -Aaron ```