On Tue, Aug 25, 2015 at 1:21 AM, Jeff King <peff@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html