2009/5/12 Hugo Mildenberger <Hugo.Mildenberger@xxxxxxxx>: >> 2009/5/11 Hugo Mildenberger <Hugo.Mildenberger@xxxxxxxx>: >> > While this was almost entirely my fault, git could possibly apply a >> > filter, reject such a name or at least issue a warning. >> >> Maybe. Or maybe it can just work (well, assuming the user meant to >> use an url with character you considered "control"). > > I said it actually did not work well, independent from how anyone prefers to > classify characters. My platform is Gentoo-hardened with unicode support and > an ext3 disk format . With "trunk directory" I meant the top level > directory which is created when you run git clone on a remote url -- sorry > for still not being a native git speaker. I don't have the original setup > anymore. My _working_ ".git/config" is now: Ok, let's assume you picked up '\r\n' from that web page > The remote url did contain something like "^J\n" at the end, as did the top > level (the much derided "trunk") directory name on disk. I probably got there > by puting the copied url within quotes on the command line, but today I'm > unsure exactly how I arrived there. However, old fashioned as I am, I still > consider e.g. a linefeed to be a "control character", and inspite of your > flashing git punditry I still consider this to be an issue. Git tries not to enforce any specific rules where the program itself does not need them. One can easily imagine an automatic system which generates names of repositories from something like binary data (something like BigTable comes to mind) and the less rules the underlying levels impose on it, the simplier the upper levels will be. OTOH, a warning about commonly used delimiters not fitting a name context, maybe a good idea. Like "\r\n\t", backslash (came up recently on this list). Such a check and associated warning may be useful for repository names and branches. Still, it's more of a policy issue and I would make it optional, even if enabled by default. Maybe even by defining a regexp which the repo name or branch name must (for hard error) or should (for a warning) match. For your specific case, you can take a look at builtin-clone.c, just after the line containing "guess_dir_name(repo_name"... -- 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