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

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

[Aaron Dufour]

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

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

[Jeff King]

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 [<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

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

[Aaron Dufour]

On Tue, Aug 25, 2015 at 1:21 AM, Jeff King <peff@peff.net> 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 [<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).

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