From: Nguyen Thai Ngoc Duy Date: Fri, 24 Dec 2010 01:39:41 GMT Subject: Re: What's cooking in git.git (Dec 2010, #06; Tue, 21) Message-ID: In-Reply-To: <4D13DCDD.3050300@workspacewhiz.com> On Fri, Dec 24, 2010 at 6:35 AM, Joshua Jensen wrote: > Having said that, I have had 100 people using the jj/icase-directory series > on Windows daily for 4 months now without issue.  Prior to that, a majority > of the series had been used for a full year by a dozen people.  In any case, > the improvement on non-case sensitive file systems is the difference between > night and day, and the series has helped prevent a number of messes that > occurred without it (git add readme.txt and git add Readme.txt, for > example... ugh...). > > More than Windows, this series also affects Mac OS X in a positive manner, > though the case sensitivity problems can be considered worse.  When you > change directories at the command line, the command line retains the case > you used to change directory, and then Git uses that case as the relative > path into the repository.  Ugh... this is different than on Windows where > the file system's directory case is retained at the Command Prompt as you > change directories.  (Cygwin actually appears to have the problem, too, but > MinGW, what msysGit is built upon, does not.) > > The Mac OS X issue listed above is not a reason not to publish the series, > though, as the fixes necessary to make that work are in completely different > areas in Git than the current jj/icase-directory series. > > Finally, I'm sitting on a bunch of other case sensitivity refinements, but > I'd like to get one series published before evolving this more.  I'd like to > get the other ones out there for discussion, but they build on the current > series. If you have not known already, path in "git log ref -- path" must be case sensitive. Solving that is not hard: ce_path_match() and tree_entry_interesting() are the ones that do path matching. Those functions are nearly replaced in this series. I'll add case-insensitive support to them, so you can worry about other places. > In reference to above, where is match_pathspec_depth()?  I can only find > match_pathspec(). Introduced in this series, nd/setup. -- Duy