{"thread":{"id":"28987","subject":"Possible bug with branch names and case sensitivity","startedAt":"2011-11-19T20:08:58Z","lastAt":"2011-11-23T22:08:36Z","messageCount":11,"participants":["Gerd Knops","Jay Soffian","Michael Haggerty","Junio C Hamano","Ævar Arnfjörð Bjarmason","Joshua Jensen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"179746","messageId":"D144F6C9-C6A3-4516-BC88-B9EB50890EF4@bitart.com","threadId":"28987","inReplyTo":null,"subject":"Possible bug with branch names and case sensitivity","fromName":"Gerd Knops","fromEmail":"gerti@bitart.com","sentAt":"2011-11-19T20:08:58Z","receivedAt":"2011-11-19T20:08:58Z","isPatch":false,"sender":{"key":"gerti@bitart.com","avatar":null},"body":"Hi All,\n\nOn Mac OS X with a case-insensitive file system (not sure if that matters) git get's confused with branch names that differ only in case. Here is what happened as far as I can reconstruct:\n\nWhile in a branch named \"foundry\" I accidentally\n\n\tgit checkout Crucible\n\ninstead of \"crucible\". This appears to have made a local branch \"Crucible\" of the remote tracking \"crucible\" branch (had I done this on purpose, I would have expected \"Crucible\" to be a branch of \"foundry\" instead of a branch of \"crucible\").\n\nI made some changes, committed, and pushed, only to be puzzled that no changes were pushed upstream.\n\nAt this point \"git branch -a\" showed:\n\n\t* Crucible\n\t  foundry\n\t  master\n\t  remotes/origin/DAExceptions\n\t  remotes/origin/HEAD -> origin/master\n\t  remotes/origin/centerSectionOptimizer\n\t  remotes/origin/crucible\n\t  remotes/origin/foundry\n\t  remotes/origin/ipad\n\t  remotes/origin/master\n\nSo naturally I proceeded with\n\n\tgit checkout crucible\n\tgit merge Crucible\n\nonly to see \"Already up-to-date.\"\n\nNot sure if any of this is expected behavior, but to me it didn't feel like it.\n\nThanks\n\nGerd\n\nPS: here is how I \"fixed\" this:\n\n\tgit checkout Crucible\n\tgit reset --soft HEAD^\n\tgit stash\n\tgit stash apply\n\t\nadded, committed, pushed. BTW now \"git branch -a\" shows:\n\n\t* crucible\n\t  foundry\n\t  master\n\t  remotes/origin/DAExceptions\n\t  remotes/origin/HEAD -> origin/master\n\t  remotes/origin/centerSectionOptimizer\n\t  remotes/origin/crucible\n\t  remotes/origin/foundry\n\t  remotes/origin/ipad\n\t  remotes/origin/master\n\nNo trace of the \"Crucible\" branch.\n"},{"id":"179798","messageId":"CAG+J_Dz6nK5fPhBRmoojmgYSv5OviN7pfgNKnRy9_9WmDS1_2w@mail.gmail.com","threadId":"28987","inReplyTo":"D144F6C9-C6A3-4516-BC88-B9EB50890EF4@bitart.com","subject":"Re: Possible bug with branch names and case sensitivity","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-11-21T19:18:03Z","receivedAt":"2011-11-21T19:18:03Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sat, Nov 19, 2011 at 3:08 PM, Gerd Knops <gerti@bitart.com> wrote:\n> On Mac OS X with a case-insensitive file system (not sure if that matters) git get's confused with branch names that differ only in case.\n\nThis is true. The branch code assumes a case-sensitive filesystem. I\nstarted working on a fix, but it was more involved than I first\nthought it would be. See my local WIP commit below, apologies if gmail\nlines wraps it.\n\nj.\n\ncommit dfa86073b7\nAuthor: Jay Soffian <jaysoffian@gmail.com>\nDate:   Thu Oct 6 14:51:15 2011 -0400\n\n    Try not to confuse branch foo with branch Foo (WIP)\n\n    This probably needs to canonicalize the branch name instead. Sigh.\n\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex a41c818a7c..0e7362345d 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -363,7 +363,7 @@ static void setup_branch_path(struct branch_info *branch)\n \tstruct strbuf buf = STRBUF_INIT;\n\n \tstrbuf_branchname(&buf, branch->name);\n-\tif (strcmp(buf.buf, branch->name))\n+\tif (strcmp_icase(buf.buf, branch->name))\n \t\tbranch->name = xstrdup(buf.buf);\n \tstrbuf_splice(&buf, 0, 0, \"refs/heads/\", 11);\n \tbranch->path = strbuf_detach(&buf, NULL);\n@@ -523,7 +523,7 @@ static void record_checkout(const char *name,\nconst char *new_work_tree)\n \t} else { /* release name if we reserved it */\n \t\tstruct branch *branch = branch_get(name);\n \t\tif (branch->work_tree &&\n-\t\t    !strcmp(branch->work_tree, get_git_work_tree()))\n+\t\t    !strcmp_icase(branch->work_tree, get_git_work_tree()))\n \t\t\tgit_config_set(key.buf, \"\");\n \t}\n \tstrbuf_release(&key);\n@@ -567,7 +567,7 @@ static void update_refs_for_switch(struct\ncheckout_opts *opts,\n \tstrbuf_addf(&msg, \"checkout: moving from %s to %s\",\n \t\t    old_desc ? old_desc : \"(invalid)\", new->name);\n\n-\tif (!strcmp(new->name, \"HEAD\") && !new->path && !opts->force_detach) {\n+\tif (!strcmp_icase(new->name, \"HEAD\") && !new->path && !opts->force_detach) {\n \t\t/* Nothing to do. */\n \t} else if (opts->force_detach || !new->path) {\t/* No longer on any branch. */\n \t\tupdate_ref(msg.buf, \"HEAD\", new->commit->object.sha1, NULL,\n@@ -582,7 +582,7 @@ static void update_refs_for_switch(struct\ncheckout_opts *opts,\n \t} else if (new->path) {\t/* Switch branches. */\n \t\tcreate_symref(\"HEAD\", new->path, msg.buf);\n \t\tif (!opts->quiet) {\n-\t\t\tif (old->path && !strcmp(new->path, old->path)) {\n+\t\t\tif (old->path && !strcmp_icase(new->path, old->path)) {\n \t\t\t\tfprintf(stderr, _(\"Already on '%s'\\n\"),\n \t\t\t\t\tnew->name);\n \t\t\t} else if (opts->new_branch) {\n@@ -612,7 +612,7 @@ static void update_refs_for_switch(struct\ncheckout_opts *opts,\n \tremove_branch_state();\n \tstrbuf_release(&msg);\n \tif (!opts->quiet &&\n-\t    (new->path || (!opts->force_detach && !strcmp(new->name, \"HEAD\"))))\n+\t    (new->path || (!opts->force_detach && !strcmp_icase(new->name, \"HEAD\"))))\n \t\treport_tracking(new);\n }\n\n@@ -719,7 +719,7 @@ static void check_if_checked_out(struct\ncheckout_opts *opts, const char *name)\n {\n \tstruct branch *branch = branch_get(name);\n \tif (branch->work_tree && strlen(branch->work_tree) &&\n-\t    strcmp(branch->work_tree, get_git_work_tree())) {\n+\t    strcmp_icase(branch->work_tree, get_git_work_tree())) {\n \t\tif (opts->force)\n \t\t\twarning(_(\"branch '%s' is currently checked out\"\n \t\t\t\t  \" in '%s'\"), name, branch->work_tree);\ndiff --git a/remote.c b/remote.c\nindex 283b2121bd..1fba1c7fa3 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -166,9 +166,9 @@ static struct branch *make_branch(const char *name, int len)\n \tchar *refname;\n\n \tfor (i = 0; i < branches_nr; i++) {\n-\t\tif (len ? (!strncmp(name, branches[i]->name, len) &&\n+\t\tif (len ? (!strncmp_icase(name, branches[i]->name, len) &&\n \t\t\t   !branches[i]->name[len]) :\n-\t\t    !strcmp(name, branches[i]->name))\n+\t\t    !strcmp_icase(name, branches[i]->name))\n \t\t\treturn branches[i];\n \t}\n\n@@ -829,7 +829,7 @@ static int query_refspecs(struct refspec *refs,\nint ref_count, struct refspec *q\n \t\t\t\tquery->force = refspec->force;\n \t\t\t\treturn 0;\n \t\t\t}\n-\t\t} else if (!strcmp(needle, key)) {\n+\t\t} else if (!strcmp_icase(needle, key)) {\n \t\t\t*result = xstrdup(value);\n \t\t\tquery->force = refspec->force;\n \t\t\treturn 0;\n"},{"id":"179814","messageId":"4ECB315F.4080701@alum.mit.edu","threadId":"28987","inReplyTo":"CAG+J_Dz6nK5fPhBRmoojmgYSv5OviN7pfgNKnRy9_9WmDS1_2w@mail.gmail.com","subject":"Re: Possible bug with branch names and case sensitivity","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-11-22T05:21:35Z","receivedAt":"2011-11-22T05:21:35Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 11/21/2011 08:18 PM, Jay Soffian wrote:\n> On Sat, Nov 19, 2011 at 3:08 PM, Gerd Knops <gerti@bitart.com>\n> wrote:\n>> On Mac OS X with a case-insensitive file system (not sure if that\n>> matters) git get's confused with branch names that differ only in\n>> case.\n> \n> This is true. The branch code assumes a case-sensitive filesystem. I \n> started working on a fix, but it was more involved than I first \n> thought it would be. See my local WIP commit below, apologies if\n> gmail lines wraps it.\n\nIs it obvious how references *should* be handled on case-insensitive\nfilesystems?  It's certainly not obvious to me (has it been discussed\nelsewhere?)  I don't think it is a good idea to \"fix\" this one problem\nwithout defining an overall policy.\n\nCurrently git handles references names case-sensitively and allows\nmultiple reference names that differ only in case.  If this behavior is\nto be preserved on case-insensitive filesystems, then either loose\nreferences must be stored differently (e.g., multiple references in the\nsame file) or ambiguous references need always to be packed.  Moreover,\ngiven a refname, we would need to be careful not to just try to open a\nfile with that name and assume that it is the correct reference; rather,\nwe would have to ask the filesystem for the name of the file in its\noriginal case and make sure that it agrees with the case of the refname\nthat we seek.\n\nBy the way, this could have ramifications for the recently-added test\nthat top-level refnames should be in ALL_CAPS.\n\nIf we want to consider bending git's behavior, there are a number of\nways we could go:\n\n1. Remain case-sensitive but prohibit refnames that differ only in case.\n\n2. Remain case-sensitive but prohibit refnames that differ only in case\n*when running on a case-insensitive filesystem*.\n\n3. Change the handling of refnames to be case-insensitive but\ncase-preserving.\n\nThe above all assumes a case-insensitive filesystem that is\n*case-preserving*.  If we want to support filesystems that do not\npreserve case, things get even more complicated.\n\nAnd if we want to pretend to support non-ASCII refnames, then the issue\nof encodings is another nasty can of worms...\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"179840","messageId":"CAG+J_DxREbykWggrD49L7qvR9M36wKL7+_kOYbvcWmLBCF2Gog@mail.gmail.com","threadId":"28987","inReplyTo":"4ECB315F.4080701@alum.mit.edu","subject":"Re: Possible bug with branch names and case sensitivity","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-11-22T17:31:33Z","receivedAt":"2011-11-22T17:31:33Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Nov 22, 2011 at 12:21 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> Is it obvious how references *should* be handled on case-insensitive\n> filesystems?  It's certainly not obvious to me (has it been discussed\n> elsewhere?)  I don't think it is a good idea to \"fix\" this one problem\n> without defining an overall policy.\n\nIndeed, I hadn't thought this through very well at all. My initial\ntake was just that if I were on a case-insensitive file system, I\ndon't get to have references that differ only in case. This is of\ncourse quite short-sighted in a distributed VCS. :-(\n\n> Currently git handles references names case-sensitively and allows\n> multiple reference names that differ only in case.  If this behavior is\n> to be preserved on case-insensitive filesystems, then either loose\n> references must be stored differently (e.g., multiple references in the\n> same file) or ambiguous references need always to be packed.  Moreover,\n> given a refname, we would need to be careful not to just try to open a\n> file with that name and assume that it is the correct reference; rather,\n> we would have to ask the filesystem for the name of the file in its\n> original case and make sure that it agrees with the case of the refname\n> that we seek.\n\nI wonder what the downside would be of always using packed refs on\ncase-insenstive file systems. This would seem analogous to how git no\nlonger uses symlinks.\n\n> By the way, this could have ramifications for the recently-added test\n> that top-level refnames should be in ALL_CAPS.\n>\n> If we want to consider bending git's behavior, there are a number of\n> ways we could go:\n>\n> 1. Remain case-sensitive but prohibit refnames that differ only in case.\n>\n> 2. Remain case-sensitive but prohibit refnames that differ only in case\n> *when running on a case-insensitive filesystem*.\n>\n> 3. Change the handling of refnames to be case-insensitive but\n> case-preserving.\n>\n> The above all assumes a case-insensitive filesystem that is\n> *case-preserving*.  If we want to support filesystems that do not\n> preserve case, things get even more complicated.\n>\n> And if we want to pretend to support non-ASCII refnames, then the issue\n> of encodings is another nasty can of worms...\n\nThese all seem like sub-optimal things to do if we can just always\nused packed refs.\n\nj.\n"},{"id":"179841","messageId":"7vwrasdp3t.fsf@alter.siamese.dyndns.org","threadId":"28987","inReplyTo":"4ECB315F.4080701@alum.mit.edu","subject":"Re: Possible bug with branch names and case sensitivity","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-22T17:49:26Z","receivedAt":"2011-11-22T17:49:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> Is it obvious how references *should* be handled on case-insensitive\n> filesystems?  It's certainly not obvious to me (has it been discussed\n> elsewhere?)  I don't think it is a good idea to \"fix\" this one problem\n> without defining an overall policy.\n\nThanks for a very sane comment.\n\n> Currently git handles references names case-sensitively and allows\n> multiple reference names that differ only in case.\n\nWe do the same for in-tree paths, by the way.  Ultimately, I think the\nsane thing to do is to appeal to the user's common sense.  In a project\nwhere its participants may use, or in a project that is about, a platform\nwhere a case-folding filesystem is the default choice, the project would\navoid in-tree paths that are different only in case and would not have\nxt_TCPMSS.c and xt_tcpmss.c at the same time.  Even though Git allows you\non such a platform to add case-conflicting pair of paths by using\n\"update-index --cacheinfo\", people would not do that, because it is not a\nuseful thing to do. And Git by default does not forbid recording such pair\nof paths, as projects for whatever reason may want to use such pair of\npaths if they know its participants can deal with case sensitivity just\nfine.\n\nI think refnames have exactly the same issue. In theory, you could have\n\"Master\" and \"master\" branches, and nothing stops you from trying to do\nso, but in practice, if it is not useful for you and your project, and\nif it is equally fine to use some other name instead of \"Master\" for the\npurpose of you and your project, then there is no strong reason for doing\nso, unless you are trying to irritate users on case folding platforms.\n"},{"id":"179842","messageId":"7vsjlgdoju.fsf@alter.siamese.dyndns.org","threadId":"28987","inReplyTo":"4ECB315F.4080701@alum.mit.edu","subject":"Re: Possible bug with branch names and case sensitivity","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-22T18:01:25Z","receivedAt":"2011-11-22T18:01:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> If we want to consider bending git's behavior, there are a number of\n> ways we could go:\n>\n> 1. Remain case-sensitive but prohibit refnames that differ only in case.\n\nI do not see a strong enough reason to be that draconian.\n\n> 2. Remain case-sensitive but prohibit refnames that differ only in case\n> *when running on a case-insensitive filesystem*.\n\nIf you make it conditional, it should be per-project, not per-repository.\nYou may be participating in a cross platform project and you may happen to\nbe on the case-sensitive system, but absense of such a check for you may\nend up hurting other participants who work on a case-insensitive one.\n\n> 3. Change the handling of refnames to be case-insensitive but\n> case-preserving.\n\nI do not see it is worth the effort. If you were to expend much effort\nthen I could see in the longer term (now I am talking about Git 2.0 in\nthis paragraph) one solution is to remove on-filesystem $GIT_DIR/refs/\nhierarchy, put it in a trivial database of some sort, keyed with case\nsensitive strings.\n\nThe transfer of refs over the wire will stay case sensitive so such a\nchange would be purely local to the repository, so transition would only\nmatter if you network mount a new style repository and attempt to use with\nolder version of Git.\n\nIf you go that route, we still would need to think about how to deal with\nthe $GIT_DIR/logs/ hierarchy, though.\n"},{"id":"179867","messageId":"4ECCB4D5.3090200@alum.mit.edu","threadId":"28987","inReplyTo":"CAG+J_DxREbykWggrD49L7qvR9M36wKL7+_kOYbvcWmLBCF2Gog@mail.gmail.com","subject":"Re: Possible bug with branch names and case sensitivity","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-11-23T08:54:45Z","receivedAt":"2011-11-23T08:54:45Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 11/22/2011 06:31 PM, Jay Soffian wrote:\n> I wonder what the downside would be of always using packed refs on\n> case-insenstive file systems. This would seem analogous to how git no\n> longer uses symlinks.\n\nThe theoretical downside is that when the total number of packed refs is\nvery large, it is more expensive to access or change a single ref if it\nis packed than if it is loose (because the whole packed refs file has to\nbe read, parsed, then rewritten, and thus scales like O(N)).  OTOH the\nnumber of references must be quite large before loose references win,\nbecause the constant factor for loose references is much larger than\nthat for packed references.  I also believe that there is still scope\nfor optimizing the handling of packed references to make them yet faster\nand perhaps even improve their scaling.\n\nBut I think that a lot of code would have to change to make this happen.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"179871","messageId":"4ECCBB3D.7070204@alum.mit.edu","threadId":"28987","inReplyTo":"7vwrasdp3t.fsf@alter.siamese.dyndns.org","subject":"Re: Possible bug with branch names and case sensitivity","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-11-23T09:22:05Z","receivedAt":"2011-11-23T09:22:05Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 11/22/2011 06:49 PM, Junio C Hamano wrote:\n> Michael Haggerty <mhagger@alum.mit.edu> writes:\n>> Currently git handles references names case-sensitively and allows\n>> multiple reference names that differ only in case.\n> \n> We do the same for in-tree paths, by the way.  Ultimately, I think the\n> sane thing to do is to appeal to the user's common sense.  [...common\n> sense aka \"if it hurts don't do it\" omitted...]\n> \n> I think refnames have exactly the same issue. In theory, you could have\n> \"Master\" and \"master\" branches, and nothing stops you from trying to do\n> so, but in practice, if it is not useful for you and your project, and\n> if it is equally fine to use some other name instead of \"Master\" for the\n> purpose of you and your project, then there is no strong reason for doing\n> so, unless you are trying to irritate users on case folding platforms.\n\nI agree.\n\nBut git could nevertheless help users (1) by providing config settings\nor hook scripts or something that could be configured in a repository to\nprevent case-conflicts from entering the project history; (2) by\nemitting an error when such a conflict arises rather than getting so\nconfused.\n\nNote that Unicode encoding differences can cause very similar problems\n(even assuming utf8, there can be multiple ways to encode the same\nstring) and should maybe be addressed similarly.\n\nBy the way, I'm not volunteering for this project; case-sensitive\nASCII's good enough for me :-)\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"179901","messageId":"7vhb1ubr70.fsf@alter.siamese.dyndns.org","threadId":"28987","inReplyTo":"4ECCBB3D.7070204@alum.mit.edu","subject":"Re: Possible bug with branch names and case sensitivity","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-23T18:59:31Z","receivedAt":"2011-11-23T18:59:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> On 11/22/2011 06:49 PM, Junio C Hamano wrote:\n>> Michael Haggerty <mhagger@alum.mit.edu> writes:\n>>> Currently git handles references names case-sensitively and allows\n>>> multiple reference names that differ only in case.\n>> \n>> We do the same for in-tree paths, by the way.  Ultimately, I think the\n>> sane thing to do is to appeal to the user's common sense.  [...common\n>> sense aka \"if it hurts don't do it\" omitted...]\n>> \n>> I think refnames have exactly the same issue. In theory, you could have\n>> \"Master\" and \"master\" branches, and nothing stops you from trying to do\n>> so, but in practice, if it is not useful for you and your project, and\n>> if it is equally fine to use some other name instead of \"Master\" for the\n>> purpose of you and your project, then there is no strong reason for doing\n>> so, unless you are trying to irritate users on case folding platforms.\n>\n> I agree.\n>\n> But git could nevertheless help users (1) by providing config settings\n> or hook scripts or something that could be configured in a repository to\n> prevent case-conflicts from entering the project history; (2) by\n> emitting an error when such a conflict arises rather than getting so\n> confused.\n\nYeah, and you didn't have to say \"But\"; we are in agreement (see my other\nmessage in response to the same message from you).\n"},{"id":"179910","messageId":"CACBZZX4qs8-u33bZbrxYS1CrwjTQc=4YOk2SUjtYzL=vc9KYgA@mail.gmail.com","threadId":"28987","inReplyTo":"CAG+J_DxREbykWggrD49L7qvR9M36wKL7+_kOYbvcWmLBCF2Gog@mail.gmail.com","subject":"Re: Possible bug with branch names and case sensitivity","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-11-23T20:50:44Z","receivedAt":"2011-11-23T20:50:44Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Nov 22, 2011 at 18:31, Jay Soffian <jaysoffian@gmail.com> wrote:\n> I wonder what the downside would be of always using packed refs on\n> case-insenstive file systems. This would seem analogous to how git no\n> longer uses symlinks.\n\nNote that Git doesn't only have confusing behavior with refs on\ncase-insensitive filesystems. The other day HFS+ users @ work had\nissues because of a case collision in the checked out tree, which\nconfused git status et al.\n\nNote that HFS+ in particular is case-insensitive *but* case\npreserving. E.g.:\n\n    $ touch Foo; perl -wle 'opendir my $d, \".\"; print while readdir\n$d; -f and print \"yes\" for qw(foo Foo FOO)'\n    .\n    ..\n    Foo\n    yes\n    yes\n    yes\n\nOn case-insensitive and not-case-preserving systems the third line\nwould usually print either \"foo\" or \"FOO\", but on HFS+ the system\npreserves the original name.\n\nThis means that you can in some cases figure out what's going on by\ndoing a readdir() in addition to a stat() as you could do on\nPOSIX-compliant systems.\n"},{"id":"179918","messageId":"4ECD6EE4.6080702@workspacewhiz.com","threadId":"28987","inReplyTo":"CACBZZX4qs8-u33bZbrxYS1CrwjTQc=4YOk2SUjtYzL=vc9KYgA@mail.gmail.com","subject":"Re: Possible bug with branch names and case sensitivity","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2011-11-23T22:08:36Z","receivedAt":"2011-11-23T22:08:36Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"----- Original Message -----\nFrom: Ævar Arnfjörð Bjarmason\nDate: 11/23/2011 1:50 PM\n>\n>\n> Note that Git doesn't only have confusing behavior with refs on\n> case-insensitive filesystems. The other day HFS+ users @ work had\n> issues because of a case collision in the checked out tree, which\n> confused git status et al.\nIs core.ignorecase set to true?  Is the repository shared with a case \nsensitive file system?\n\nI have a patch sitting around for 'git update-index --add' that fixes \nsome case insensitivity issues, especially when using Git Gui.  This \npatch complements the core.ignorecase patches I sent in the past.\n\n-Josh\n"}]}