Casey Meijer <cmeijer@xxxxxxxxxxxxxxxxxxxxx> writes: > Sorry I got mixed up,, that last message should have been > addressed to Junio. > > My apologies. > > To put it very simply, I'm asking that git respect the separation > of concerns between itself and its storage engine (regardless of > whether that's pluggable, or just the current filesystem, which I > guess is technically pluggable, lol). If "git" is told to store ref 'foo' pointing at object X and then ref 'Foo' pointing at object Y by the end user, after claiming to have done these two operations, if it is then asked about the value of 'foo', it must say that 'foo' points at object X and not Y. If a ref backend is based on case insensitive filesystem, there are only two options available. (1) ignore case and violate the expectation of end user. (2) come up with a way to "defeat" the limitation of case insensitivity imposed by the filesystem (e.g. your ref backend implementation _could_ URLencode/decode the ref before using it as a filename on such a filesystem). Doing (2) would be transparent to the rest of Git (i.e. the rest of Git does not have to care that each ref is stored in a file, whose filename is encoded version of the refname) and gives us a good separation of concerns between it and the storage backend. Those who ported Git to case insensitive filesystems didn't and chose (1). As (1) violates end-user expectation, I would think it is fair to declare it a bug.
