Re: [PATCH 2/2] Improve the naming of guessed target repository for git clone

Am Donnerstag, 14. Mai 2009 schrieb Alex Riesen:

2009/5/14 Junio C Hamano [off-list ref]:

quoted

Alex Riesen [off-list ref] writes:

quoted

quoted

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.

quoted

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.

quoted

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.

quoted

... 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.