On Wed, 29 April 2009, Martin Langhoff wrote: > On Tue, Apr 28, 2009 at 1:24 PM, Jakub Narebski <jnareb@xxxxxxxxx> > wrote: [I think you cut out a bit too much. Here I resurrected it] JN> 1. Different limitations on file names (e.g. pathname length), JN> different special characters, different special filenames JN> (if any). [...] JN> The answer is convention for filenames in a project. Simply JN> DON'T use filenames which can cause problems. [...] > > DON'T DO THAT. What could be proper solution to that, if you do not accept social rather than technical restriction? We can have pre-commit hook that checks for portability for filenames (which is deployment specific, and shouldn't be part of SCM perhaps with an exception of being example hook) but it wouldn't help dealing with non-portable filenames on filesystem that cannot represent them that are there. If I remember correctly Git for some time has layer which can translate between filenames in repository and filenames on filesystem, but I'm not sure if it is generic enough for it to be a solution to this problem, and currently there is no way to manipulate this mapping, I think. JN> 2. "Case-insensitive" but "case-preserving" filesystems. [...] JN> JN> The answer is like for previous issue: don't. Simply DO NOT JN> create files with filenames which differ only in case [...] > > DON'T DO THAT, SOLVABLE. By 'solvable' here I mean that you should be able to modify only one of clashing files at once (checkout 'README', modify, add to index, remove from filesystem, checkout 'readme', modify, etc.), and deal with annoyances in git-status output. It can be done in Git, with medium amount of hacking. I don't think any other SCM can do even this, and I cannot think of a better, automatic solution that would somehow deal with case-clashing. Note that all deals are off in case-insensitive and not preserving filesystem. By the way, wouldn't be a better solution to use sane filesystem, rather than complicating SCM? ;-) > > As I mentioned, Eric is taking the perspective of offering a supported > SCM to a large and diverse audience. As such, his notes are > interesting not because he's right or he's wrong. > > We can be "right" and say "don't do that" if we shrink our audience so > that it looks a lot like us. There, fixed. <quote source="Dune by Frank Herbert"> [...] the attitude of the knife — chopping off what's incomplete and saying: "Now it's complete because it's ended here." </quote> I could not resist posting this quote :-P > > But something tells me that successful tools are -- by definition -- > tools that grow past their creators use. > > So from Eric's perspective, it is worthwhile to work on all those > issues, and get the right for the end user -- support things we don't > like, offer foolproof catches and warnings that prevent the user from > shooting their lovely toes off to mars, etc. Warnings and catches I can accept; adding complications and corner cases for situations which can be trivially avoided with a bit of social engineering aka. project guidelines... not so much. I simply cannot see the situation where you _must_ have dangerously unportable file names (trailing dot, trailing whitespace) and case-clashing files... > > His perspective is one of commercial licensing, but even if we aren't > driven by the "each new user is a new dollar" bit, the long term hopes > for git might also be to be widely used and to improve the version > control life of many unsuspecting users. > > To get there, I suspect we have to understand more of Eric's > perspective. > > that's my 2c. By the way, I think that the article on cross-platform version control (version control in heterogenic environment) is quite good article. I don't quite like the "10 Issues"/"Top 10" way of writing, but the article examines different ways that heterogenic environment can trip SCM. In my opinion Git does quite good here, where it can, and where the issue is to be solved by SCM and not otherwise (extra metadata like resource fork). -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html