Re: [PATCH 0/6] Extensions of core.ignorecase=true support

So apparently when core.ignorecase=true, this really means
casepreserving=false, casesensitive=true. Yet when
core.ignorecase=false it actually means casepreserving=true,
casesensitive=true. That's what I infer from the git-config
documentation. Would you agree?

On Tue, Aug 17, 2010 at 5:20 PM, Johannes Sixt [off-list ref] wrote:

On Dienstag, 17. August 2010, Robert Buck wrote:

quoted

While I tend to agree with case-insensitive searches, I would tend to
question the use of a non-case-preserving / last-use methodology
reminiscent of the days of DOS.

There is no "last-use" involved. Everything's rather "first-use", i.e.,
case-preserving.

quoted

The nice thing about case-insensitivity is that when requesting a file
by name any capitalization can be used. The bad thing, well come to
think of it, there is none that I can think of, but for those more
religious than I about Unix they may cite otherwise.

What do you mean by "requesting a file"?

core.ignorecase is purely about the worktree and the transition of files from
the worktree to the index. It is *not* involved when files are moved from the
index or the repository to the worktree. In particular, it is not used when
you give a pathspec to limit 'git log' results. (Joshua proposed a change
where core.ignorecase would also kick in in this case as well, but this
change is not included in this series, and I would not agree to it.)

So what I am hearing is that unless one sets core.ignorecase, in mixed
environments you are in for a world of hurt; you'd end up with Foo and
foo from the Unix side of the house, and on Macs or Windows the last
file materialized from the index or repository into the working
directory would clobber the first one materialized, potentially
introducing relatively quiescent bugs that could make their way into
production environments.