From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Subject: RFD: Handling case-colliding filenames on case-insensitive filesystems
Date: Wed, 23 Feb 2011 18:11:45 +0100 [thread overview]
Message-ID: <201102231811.45948.johan@herland.net> (raw)
Hi,
At $dayjob we recently had a problem where a developer pushed a commit
that added new files, two of which were named "foobar.TXT"
and "FOOBAR.txt". When this commit (or anything based on it) is checked
out by one of our Windows developers, Git maps two files in its index
to a single file on the filesystem, and ends up reporting a diff on one
of those files. The diff won't go away unless one (or both) of the
case-colliding files is removed from the repo. Obivously, the
persisting diff prevents the developer from easily rebasing, switching
branches, merging, bisecting and a number of other useful tasks.
The root of the problem is that the case-colliding files were added in
the first place, and this should obviously be prevented in projects
that aim to be compatible with case-insensitive filesystems. To that
end, I'm currently writing an update hook which will prevent
case-colliding files from being pushed to our central repo.
However, given that this has already happened, how can we design Git to
handle this situation more gracefully. In other words, how can we
better handle checking out filenames that collide on case-insensitive
filesystems?
My first idea was to simply refuse checking out trees with
case-colliding filenames. I.e. when core.ignoreCase is enabled, we
check whether any of the files we're about to checkout map to the same
filesystem representation, and if they do, we abort the checkout and
complain loudly to the user. However, that doesn't really help the user
at all. Failure to checkout would only make it much harder to fix the
issue.
A colleague suggested instead that Git should notice that the collision
will occur, and work around the failure to represent the repository
objects in the file system with a one-to-one match. Either by checking
out only _one_ of the colliding files, or by using a non-colliding name
for the second file. After all, Git already has functionality for
manipulating the file contents on checkout (CRLF conversion). Doesn't
it make sense to add functionality for manipulating the _directory_
contents on checkout as well? Even if that makes sense, I'm not sure
that implementing it will be straightforward.
Are there better suggestions on how to deal with this?
Thanks,
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
next reply other threads:[~2011-02-23 17:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 17:11 Johan Herland [this message]
2011-02-23 18:56 ` RFD: Handling case-colliding filenames on case-insensitive filesystems Junio C Hamano
2011-02-23 19:01 ` Shawn Pearce
2011-02-23 19:27 ` Junio C Hamano
2011-02-24 0:58 ` Johan Herland
2011-02-24 1:26 ` Junio C Hamano
2011-02-24 8:50 ` Johan Herland
2011-02-23 19:07 ` Jay Soffian
2011-02-23 19:17 ` Matthieu Moy
2011-02-23 22:52 ` Marc Branchaud
2011-02-23 23:09 ` Greg Troxel
2011-02-24 0:30 ` Johan Herland
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=201102231811.45948.johan@herland.net \
--to=johan@herland.net \
--cc=git@vger.kernel.org \
/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).