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

[Aaron Dufour <thedufer@gmail.com>]

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