Am 28.02.2014 07:41, schrieb Johannes Sixt: > Am 2/28/2014 0:38, schrieb Lee Hopkins: >>> If I understand the issue correctly, the problem is that packed-refs >>> are always case-sensitive, even if core.ignorecase=true. OTOH, > > core.ignorecase is intended to affect filenames of the worktree, not > anything else, BTW. > from git-config(1): "enables various workarounds to enable git to work better on filesystems that are not case sensitive" It says nothing about work-tree only, so I'd expect it to apply to all git components that store potentially case-sensitive information in file names. ...it also says "better", not "flawlessly" :-) >>> checking / updating _unpacked_ refs on a case-insensitive file system >>> is naturally case-insensitive. So wouldn't it be a better workaround >>> to disallow packed refs (i.e. 'git config gc.packrefs false')? >> >> You are correct, the issue boils down to mixing the usage of >> packed-refs and loose refs on case insensitive file systems. So either >> always using packed-refs or always using loose refs would take care of >> the problem. Based Michael Haggerty's response, it seems that always >> using loose refs would be a better workaround. > > So, everybody on a case-insensitive file system should pay the price even > if they do not need the "feature"? No way. > > If you are on a case-insensitive filesystem, or work on a cross-platform > project, ensure that you avoid ambiguous refs. Problem solved. > So its OK to lose data if you accidentally use an ambiguous ref? I cannot believe you actually meant that. IMO the proper solution is to teach packed-refs about core.ignorecase. Until that happens, disabling gc.packrefs seems to be a valid workaround for people who have that problem. -- 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