From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dmitry Potapov <dpotapov@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>,
Frank <streamlake@tiscali.it>
Subject: Re: [PATCH 0/7] Case-insensitive filesystem support, take 1
Date: Tue, 25 Mar 2008 14:04:58 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.00.0803251347400.2775@woody.linux-foundation.org> (raw)
In-Reply-To: <20080325081409.GI25381@dpotapov.dyndns.org>
On Tue, 25 Mar 2008, Dmitry Potapov wrote:
>
> - merge different branches were two file names are only differ by case
> will cause that the result branch has two file names that differ only
> by case and one of them will be overwritten by the other and shown as
> modified in the worktree by git status.
Ok. So there's two issues here:
- the git trees themselves had two different names
This is not something I'm *ever* planning on changing. All my "case
insensitive" patches were about the *working*tree*, not about core git
data structures themselves.
In other words: git itself is internally very much a case-sensitive
program, and the index and the trees are case-sensitive and will remain
so forever as far as I'm concerned. So when you do a tree-level merge
of two trees that have two different names that are equivalent in case,
git will create a result that has those two names. Because git itself
is not case-insensitive.
- HOWEVER - when checking things out, we should probably notice that
we're now writing the two different files out and over-writing one of
them, and fail at that stage. I don't know what a good failure
behaviour would be, though. I'll have to think about it.
IOW, all my case-insensitivity checking was very much designed to be about
the working tree, not about git internal representations. Put another way,
they should really only affect code that does "lstat()" to check whether
a file exists or code that does "open()" to open/create a file.
> - git status cares only about case-insensitivity only for files and not
> for directories. Thus, if case of letters in a directory name is changed
> then this directory will be shown as untracked.
Ahh, yes. This is sad. It comes about because while we can look up whole
names in the index case-insensitively, we have no equivalent way to look
up individual path components, so that still uses the "index_name_pos()"
model and then looking aroung the failure point to see if we hit a
subdirectory. Remember: the index doesn't actually contain directories at
all, just lists of files.
This will not be trivial to fix.
> - pattern specified in .gitignore are match as case-sensitive despite
> core.ignorecase set to true.
This should probably be fairly straightforward. All the logic here is in
the function "excluded_1()" in dir.c - and largely it would be about
changing that "strcmp()" into a "strcasecmp()" and using the FNM_CASEFOLD
flag to fnmatch().
The only half-way subtle issues here are
- do we really want to use strcasecmp() (which may match differently than
our hashing matches!) or do we want to expand on our icase_cmp() or
similar in hash-name.c (I think the latter is the right thing, but it
requires a bit more work)
- FNM_CASEFOLD has the same issue, but also adds the wrinkle of being a
GNU-only extension. Which is sad, since most systems that have glibc
would never need it in the first place. So then we get back to the
whole issue of maybe having to reimplement 'fnmatch()', or at least a
subset of it that git uses.
So that last issue is conceptually simple and straightforward to fix, but
fixing it right would almost certainly be a few hundred lines of code
(fnmatch() in particular is nasty if you want to do all the cases, but
perhaps just '*' is ok?).
The first two issues are nontrivial.
Linus
next prev parent reply other threads:[~2008-03-25 21:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-22 17:21 [PATCH 0/7] Case-insensitive filesystem support, take 1 Linus Torvalds
2008-03-22 17:22 ` [PATCH 1/7] Make unpack_trees_options bit flags actual bitfields Linus Torvalds
2008-03-22 17:25 ` [PATCH 2/7] Move name hashing functions into a file of its own Linus Torvalds
2008-03-22 17:28 ` [PATCH 3/7] Make "index_name_exists()" return the cache_entry it found Linus Torvalds
2008-03-22 17:30 ` [PATCH 4/7] Make hash_name_lookup able to do case-independent lookups Linus Torvalds
2008-03-22 17:33 ` [PATCH 5/7] Add 'core.ignorecase' option Linus Torvalds
2008-03-22 17:38 ` [PATCH 6/7] Make branch merging aware of underlying case-insensitive filsystems Linus Torvalds
2008-03-22 17:45 ` [PATCH 7/7] Make unpack-tree update removed files before any updated files Linus Torvalds
2008-03-22 18:06 ` [PATCH 0/7] Final words Linus Torvalds
2008-03-22 18:28 ` Linus Torvalds
2008-03-22 21:19 ` [PATCH 8/7] When adding files to the index, add support for case-independent matches Linus Torvalds
2008-03-22 21:22 ` [PATCH 9/7] Make git-add behave more sensibly in a case-insensitive environment Linus Torvalds
2008-03-23 5:49 ` [PATCH 7/7] Make unpack-tree update removed files before any updated files Junio C Hamano
2008-03-23 6:13 ` [PATCH 6/7] Make branch merging aware of underlying case-insensitive filsystems Junio C Hamano
2008-03-23 15:41 ` Linus Torvalds
2008-03-22 17:36 ` [PATCH 1/7] Make unpack_trees_options bit flags actual bitfields Johannes Schindelin
2008-03-22 17:47 ` Linus Torvalds
2008-03-22 17:57 ` Johannes Schindelin
2008-03-22 22:01 ` [PATCH] t0050: Set core.ignorecase case to activate case insensitivity Steffen Prohaska
2008-03-25 6:57 ` [PATCH] git-init: autodetect core.ignorecase Dmitry Potapov
2008-03-25 9:59 ` Johannes Schindelin
2008-03-25 10:49 ` [PATCH v2] " Dmitry Potapov
2008-03-25 11:03 ` [PATCH] " Dmitry Potapov
2008-03-25 8:14 ` [PATCH 0/7] Case-insensitive filesystem support, take 1 Dmitry Potapov
2008-03-25 21:04 ` Linus Torvalds [this message]
2008-03-26 2:46 ` Dmitry Potapov
2008-03-26 3:37 ` Linus Torvalds
2008-03-25 11:39 ` Derek Fawcus
2008-03-25 18:26 ` Jan Hudec
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.1.00.0803251347400.2775@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=dpotapov@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=streamlake@tiscali.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).