Thread (12 messages) flat view 12 messages, 2 authors, 2016-06-15

Re: git fails with control characters in trunk directory name

From: Alex Riesen <hidden>
Date: 2016-06-15 22:46:45

2009/5/12 Hugo Mildenberger [off-list ref]:
quoted
2009/5/11 Hugo Mildenberger [off-list ref]:
quoted
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"...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help