Am Donnerstag, 14. Mai 2009 schrieb Alex Riesen: > 2009/5/14 Junio C Hamano <gitster@xxxxxxxxx>: > > Alex Riesen <raa.lkml@xxxxxxxxx> writes: > > > >>> What's the point of this change, now that you have a fix in 1/2? Who are > >>> you helping with this patch? > >> > >> Without this the _automatically_ generated names for cloned repositories > >> have all the whitespace around them. > > > > Even if it has whitespace around its name, that's what you got from the > > upstream (a valid source of clone), and wasn't it you who said something > > about UNIX tradition of allowing LF and others in the filename? > > Yes, when user explicitely asked a program about that. This here > (clone with only URL as argument) is not the case, I think. > > > If clone reports "ok we created this new repository" so that the caller > > can capture it, then the whole process should be able to cope with > > automatically generated names with or without the patch, shouldn't it? > > No, don't think so. You're not always able to capture the output of git clone > (Windows again), and BTW - init-db output is not designed to be captured > unambiguously. > > > Or are you trying to help a human user who gives a pathname ridden with > > excess whitespaces to "git clone", and that pathname _happens_ to work as > > a valid clone source, creating a new repository whose name is ridden with > > excess whitespaces the same way as the input pathname? > > Not really. I just try to make the _generated_ output, which the user cannot > predict anyway (nor does the user care much about it) to be less > problematic. Yes, I did say that LF-anything in UNIX filenames is a normal > thing. That does not mean that such names are so very convenient to use. > They do cause problems, even if just through scrambling terminal output. > They are "inconvenient". If our users don't expect precise output anyway, > we can be a little more adhering to usual practices in choosing names. > > > ... After all, the > > user deliberately gave them to us, and the repository we cloned from had > > these excesses in its name (iow, without the excess whitespaces the clone > > itself wouldn't have worked). In such a case, is it really helping him to > > remove these whitespaces as excesses? > > I think yes. Otherwise the strict form of git clone could have been used, > which involves absolutely no guessing and mangling. > This discussion began with the problem I encountered during a git clone operation applied to an url which accidentally included a linefeed. It partly went through although the remote side did not include that character. After Alex Riesen fixed the git part by escaping linefeeds, the linefeed left over in the top level directory name still caused a linux kernel make to fail (which really is not problem of git or GNU make itself). Elsewhere in this thread, Daniel Barkalow proposed to apply the HTTP RFC to the whole url. If accepted, this would cope with the problem in a standard way. -- 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