Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 24, 2010, 19:23 UTC
- Message-ID
- <7vzkrvynz5.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4D13DCDD.3050300@workspacewhiz.com>
Joshua Jensen <jjensen@workspacewhiz.com> writes:
Show 31 quoted lines
> From: Junio C Hamano > Date: 12/23/2010 10:17 AM >> Nguyen Thai Ngoc Duy<pclouds@gmail.com> writes: >> >>> On Wed, Dec 22, 2010 at 8:59 AM, Junio C Hamano<gitster@pobox.com> wrote: >>> With jj/icase-directory merged to master, match_pathspec() and >>> match_pathspec_depth() now diverse again. >>> >>> When I wrote match_pathspec_depth(), I assumed that match_pathspec() >>> would not change much and I would have more time for converting the >>> rest of git to use match_*_depth(). Looks like I need to add case >>> insensitive matching to struct pathspec and friends then remove >>> match_pathspec() in this series too. At least if somebody changes >>> match_pathspec() again, it would cause a conflict so I can catch it. >> While this topic is something I have long wanted to see, I have started >> feeling that this needs to cook a bit longer than be in the next release. >> So perhaps the best course of action might be to rebase the series once >> after the 1.7.4 feature freeze, cook it in 'next' for a while and make it >> part of the release after that. I think at that point we may probably >> want to have other changes that are not strictly backward compatible but >> their incompatibilities do not matter in practice (e.g. cquoting pathspecs >> in the attributes file comes to mind, but I am sure there will be other >> changes that people wanted to have but we held them off due to worries on >> compatibility). >> >> What do you think? > ... > 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....
Just to make sure nobody misunderstood me, what I was proposing to put on hold was not the "case insensitivity" work of yours, which is already scheduled to be part of the coming release.