Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Dec 24, 2010, 01:39 UTC
- Message-ID
- <AANLkTikaBfVw-4eD9qeGSdM5xKxq-gJ-3oAe4B2qt4od@mail.gmail.com>
- In-Reply-To
- <4D13DCDD.3050300@workspacewhiz.com>
On Fri, Dec 24, 2010 at 6:35 AM, Joshua Jensen <jjensen@workspacewhiz.com> wrote:
Show 25 quoted lines
> 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