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

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

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.

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.