[PATCH] Git homepage: remove all the references to Cogito

[PATCH] Git homepage: remove all the references to Cogito

[Paolo Ciarrocchi]

It sounds like a good idea to remove all the references to Cogito from the git homepage since it's not longer supported.
Changes tested with a local installation of the web server lighttpd

Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
 index.html |   12 +-----------
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/index.html b/index.html
index 340aee0..41605ed 100644
--- a/index.html
+++ b/index.html
@@ -94,7 +94,6 @@ Junio C Hamano.</p>
 	-->
 	<br /><a href="course/stgit.html">Maintaining external patches</a>
 	<br /><a href="course/svn.html">Git for SVN users</a>
-	<br /><a href="course/cvs.html">Cogito for CVS users</a>
 	<br /><em>More to come soon...</em>
 	</tr></td>
 </table></div>
@@ -286,15 +285,6 @@ a gitweb interface, at <a href="http://repo.or.cz/">http://repo.or.cz/</a>.</p>
 
 <dl>
 
-<dt id="cogito">Cogito</dt>
-<dd>
-<a href="http://git.or.cz/cogito/">Cogito</a>
-is a popular version control system on top of Git.
-It aims at seamless user interface and ease of use, providing
-generally smoother user experience than the "raw" Git interface
-and indeed also many other version control systems. However, it
-also lacks many advanced capabilities of Git and is currently
-being slowly phased out.</dd>
 
 <dt id="stgit">StGIT</dt>
 <dd><a href="http://www.procode.org/stgit/">Stacked Git</a> provides
@@ -340,7 +330,7 @@ with help of a group of hackers 'round the net.
 It is currently maintained by
 Junio C Hamano.</p>
 
-<p>The user discussion and development of Git, Cogito and other tools related to Git
+<p>The user discussion and development of Git and other tools related to Git
 takes place on the Git mailing list - everyone is welcome to post
 bug reports, feature requests, comments and patches to
 <a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>.
-- 
1.5.3.4.206.g58ba4

Re: [PATCH] Git homepage: remove all the references to Cogito

[Petr Baudis]

On Mon, Oct 15, 2007 at 11:38:00PM +0200, Paolo Ciarrocchi wrote:
> @@ -286,15 +285,6 @@ a gitweb interface, at <a href="http://repo.or.cz/">http://repo.or.cz/</a>.</p>
>  
>  <dl>
>  
> -<dt id="cogito">Cogito</dt>
> -<dd>
> -<a href="http://git.or.cz/cogito/">Cogito</a>
> -is a popular version control system on top of Git.
> -It aims at seamless user interface and ease of use, providing
> -generally smoother user experience than the "raw" Git interface
> -and indeed also many other version control systems. However, it
> -also lacks many advanced capabilities of Git and is currently
> -being slowly phased out.</dd>
>  
>  <dt id="stgit">StGIT</dt>
>  <dd><a href="http://www.procode.org/stgit/">Stacked Git</a> provides

I'm not sure this is good idea, Cogito is still quite frequently used
and it should be documented that it exists.

-- 
				Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
                -- James Thurber

Re: [PATCH] Git homepage: remove all the references to Cogito

[Matthieu Moy]

Petr Baudis <pasky@suse.cz> writes:

> I'm not sure this is good idea, Cogito is still quite frequently used
> and it should be documented that it exists.

I think reformulating the mention to cogito (use past sentence like
"cogito was a popular ...") would be better. As a side-effect, it
would also credit you for your work, which I think is fair :-).

-- 
Matthieu

Re: [PATCH] Git homepage: remove all the references to Cogito

[Paolo Ciarrocchi]

On 10/16/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > I'm not sure this is good idea, Cogito is still quite frequently used
> > and it should be documented that it exists.
>
> I think reformulating the mention to cogito (use past sentence like
> "cogito was a popular ...") would be better. As a side-effect, it
> would also credit you for your work, which I think is fair :-).

Yes, I probably be too rude. Sorry abot that Pasky, I just feel like
the home page is a bit confusing with regards to Cogito. My
understanding is that it is no longer maintained and therefore we
probably should not encourage new user to use it.

Maybe changing:
Cogito
    Cogito is a popular version control system on top of Git. It aims
at seamless user interface and ease of use, providing generally
smoother user experience than the "raw" Git interface and indeed also
many other version control systems. However, it also lacks many
advanced capabilities of Git and is currently being slowly phased out.

into
Cogito
    Cogito was a popular version control system on top of Git. It aims
at seamless user interface and ease of use, providing generally
smoother user experience than the "raw" Git interface and indeed also
many other version control systems. However, it also lacks many
advanced capabilities of Git and is not actively maintained any
longer.

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

[PATCH] gitweb: Speed up get_projects_list for large source trees

[Luke Lu]

Hi, I've been using git for a month now and loving it. This is my  
first ever patch for git using git. I spent sometime to find out why  
the project listing is taking 200s, everytime! I guess that gitweb is  
mostly used to serve bare repositories, which would never encounter  
such problems. It takes .2s, after the patch on my laptop. That's  
1000x improvement for me (on Mac OS X 1.4.10.)

__Luke

Signed-off-by: Luke Lu <git@vicaya.com>
---
gitweb/gitweb.perl |    4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3064298..a30eef9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1509,16 +1509,20 @@ sub git_get_projects_list {
		# remove the trailing "/"
		$dir =~ s!/+$!!;
		my $pfxlen = length("$dir");
+		my $pfxdepth = ($dir =~ tr!/!!);
		File::Find::find({
			follow_fast => 1, # follow symbolic links
			follow_skip => 2, # ignore duplicates
+			no_chdir => 1, # don't chdir into every directory
			dangling_symlinks => 0, # ignore dangling symlinks, silently
			wanted => sub {
				# skip project-list toplevel, if we get it.
				return if (m!^[/.]$!);
				# only directories can be git repositories
				return unless (-d $_);
+				# don't traverse too deep (Find is super slow on os x)
+				return if tr!/!! - $pfxdepth > 2 && ($File::Find::prune = 1);
				my $subdir = substr($File::Find::name, $pfxlen + 1);
				# we check related file in $projectroot
--
1.5.3.4

Re: [PATCH] gitweb: Speed up get_projects_list for large source trees

[Andreas Ericsson]

Luke Lu wrote:
> Hi, I've been using git for a month now and loving it.

Hello Luke, and welcome to the community :)

> This is my first ever patch for git using git.

It shows. The patch is whitespace damaged, and the commit message leaves
a little something to desire. I suggest you read through
Documentation/SubmittingPatches and then re-send your patch. Try sending
to yourself and looking at the result with a monospace font. It's what I
always do to make sure patches look okay before sending them to the list.

Not trying to be rude or anything. Oldtime list-members sometimes get to
hear the exact same thing.

Also, Junio, the maintainer, is currently away, so don't worry if your
patches are left in limbo for some time. Someone will pick it up and
carry it forward for Junio to pull, or he'll hack up some script to
get all patces from his mailbox and review them one by one. He's a very
thorough fellow, usually.

> I spent sometime to find out why the 
> project listing is taking 200s, everytime! I guess that gitweb is mostly 
> used to serve bare repositories, which would never encounter such 
> problems. It takes .2s, after the patch on my laptop. That's 1000x 
> improvement for me (on Mac OS X 1.4.10.)
> 

Sweet job :)

I'll have to test this, as we've got a few repos at work with a checked out
working tree connected to the repos. I haven't run into your issues though,
but perhaps that's because we run it under Linux.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [PATCH] gitweb: Speed up get_projects_list for large source trees

[Petr Baudis]

  Hi,

On Tue, Oct 16, 2007 at 02:04:14AM -0700, Luke Lu wrote:
> Hi, I've been using git for a month now and loving it. This is my first 
> ever patch for git using git. I spent sometime to find out why the project 
> listing is taking 200s, everytime! I guess that gitweb is mostly used to 
> serve bare repositories, which would never encounter such problems. It 
> takes .2s, after the patch on my laptop. That's 1000x improvement for me 
> (on Mac OS X 1.4.10.)

  that'd be sweet to have but this is unfortunately not so simple; this
change would e.g. break gitweb on repo.or.cz, where some projects can
live quite deep inside the tree due to forks.

  I guess the best way would be to introduce a configuration option that
lets you potentially limit the $pfxdepth, but does not force the limit.

-- 
				Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
                -- James Thurber

cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito

[Johannes Schindelin]

Hi,

On Tue, 16 Oct 2007, Petr Baudis wrote:

> On Mon, Oct 15, 2007 at 11:38:00PM +0200, Paolo Ciarrocchi wrote:
> > @@ -286,15 +285,6 @@ a gitweb interface, at <a href="http://repo.or.cz/">http://repo.or.cz/</a>.</p>
> >  
> >  <dl>
> >  
> > -<dt id="cogito">Cogito</dt>
> > -<dd>
> > -<a href="http://git.or.cz/cogito/">Cogito</a>
> > -is a popular version control system on top of Git.
> > -It aims at seamless user interface and ease of use, providing
> > -generally smoother user experience than the "raw" Git interface
> > -and indeed also many other version control systems. However, it
> > -also lacks many advanced capabilities of Git and is currently
> > -being slowly phased out.</dd>
> >  
> >  <dt id="stgit">StGIT</dt>
> >  <dd><a href="http://www.procode.org/stgit/">Stacked Git</a> provides
> 
> I'm not sure this is good idea, Cogito is still quite frequently used
> and it should be documented that it exists.

I agree.  But maybe it could be marked as unmaintained?  Maybe someone 
steps up to maintain it.  Or, even better, comes up with a list of "this 
is what I like do regularly with cogito, but there's no easy way with core 
git" issues.

In related news, I recently thought about the url#branch issue.

There were three arguments against it AFAIR: "#" is a comment marker, and 
this syntax is not extensible to more than one branch names.  And that the 
branch name is not really a part of the URL.

Turns out that I am not so sure about the last two issues.

It is easily extensible to more than one branch by remote#branch1#branch2, 
and in a very real sense, this is a resource locator.

And we could replace the "#" by every character that is illegal in ref 
names as well as URLs.  I propose SPC.  ('#' is allowed in refnames.)

Ciao,
Dscho

Re: remote#branch

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On Tue, Oct 16, 2007 at 11:49:58 +0100, Johannes Schindelin wrote:
> In related news, I recently thought about the url#branch issue.
> 
> There were three arguments against it AFAIR: "#" is a comment marker, and 
> this syntax is not extensible to more than one branch names.  And that the 
> branch name is not really a part of the URL.
> 
> Turns out that I am not so sure about the last two issues.
> 
> It is easily extensible to more than one branch by remote#branch1#branch2, 
> and in a very real sense, this is a resource locator.
> 
> And we could replace the "#" by every character that is illegal in ref 
> names as well as URLs.  I propose SPC.  ('#' is allowed in refnames.)

It's a question, whether the branch name is part of the URI, or a fragment.

Current usage suggests it is a fragment, but according to the URL
specification that is supposed to mean that the resource is always accessed
the same (fragment is NOT part of the URL) and the fragment only affects
local handling. Which I don't think is really true.

If it is a fragment, than "#" is the only correct separator and should stay
that way.

If it is not a true fragment, than we might want to phase it out in favor of
something else. But I would strongly prefer staying within characters allowed
in URI (as per rfc2396). We could consider whether the branch is not
a component parameter -- which would imply ";" as separator, but I would vote
against that on the basis that it's shell special. Non-special characters
allowed by URL in this context would be ":", "@", "=", "+", and ",", of which
":" or "@" seem best to me.

As for multiple branches, separating them with "," feels logical to me, no
matter what separates them from the repository path. On the other hand given
that neither ":" nor "@" is allowed in refnames, reusing the same separator
would make sense especially if git switched to either of those.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: remote#branch

[Johannes Schindelin]

Hi,

On Tue, 16 Oct 2007, Jan Hudec wrote:

> If it is a fragment, than "#" is the only correct separator and should 
> stay that way.

You did not listen, did you?  '#' is allowed in ref names.  Therefore this 
character really would lock us in to only ever reference _one_ and _only_ 
one remote branch at a time.  This might have worked for cogito, but it 
does not for git.

So, I say it again, '#' is _out_.

> If it is not a true fragment, than we might want to phase it out in 
> favor of something else. But I would strongly prefer staying within 
> characters allowed in URI (as per rfc2396).

If you do that, "http://<xyz-with-branch>" would be ambiguous, wouldn't 
it?  This would already reference an HTTP resource, and you could not 
embed refnames into the URL.

> As for multiple branches, separating them with "," feels logical to me, 
> no matter what separates them from the repository path. On the other 
> hand given that neither ":" nor "@" is allowed in refnames, reusing the 
> same separator would make sense especially if git switched to either of 
> those.

',' is allowed in ref names, so ',' is out.

Ciao,
Dscho

Re: remote#branch

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 16 Oct 2007, Jan Hudec wrote:
> 
> > If it is a fragment, than "#" is the only correct separator and should 
> > stay that way.
> 
> You did not listen, did you?  '#' is allowed in ref names.  Therefore this 
> character really would lock us in to only ever reference _one_ and _only_ 
> one remote branch at a time.  This might have worked for cogito, but it 
> does not for git.
> 
> So, I say it again, '#' is _out_.

That does not imply it can't separate the ref from the repository...

> > If it is not a true fragment, than we might want to phase it out in 
> > favor of something else. But I would strongly prefer staying within 
> > characters allowed in URI (as per rfc2396).
> 
> If you do that, "http://<xyz-with-branch>" would be ambiguous, wouldn't 
> it?  This would already reference an HTTP resource, and you could not 
> embed refnames into the URL.

... and because of this actually has to. You are right.

> > As for multiple branches, separating them with "," feels logical to me, 
> > no matter what separates them from the repository path. On the other 
> > hand given that neither ":" nor "@" is allowed in refnames, reusing the 
> > same separator would make sense especially if git switched to either of 
> > those.
> 
> ',' is allowed in ref names, so ',' is out.

Actually since many characters that are allowed in ref name are not allowed
in URL at all, the ref-name has to be url-escaped. Which brings all
characters back in, because they can always be specified escaped.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: remote#branch

[Johannes Schindelin]

Hi,

On Sat, 27 Oct 2007, Jan Hudec wrote:

> On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:
>
> > ',' is allowed in ref names, so ',' is out.
> 
> Actually since many characters that are allowed in ref name are not 
> allowed in URL at all, the ref-name has to be url-escaped. Which brings 
> all characters back in, because they can always be specified escaped.

No.  The URL part of it has to be encoded.  But the ref names do _not_.  
(If we really want to have a way to specify the remote URL and the 
branch(es) we want to fetch _at the same time_.)

Ciao,
Dscho

Re: remote#branch

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

On Sun, Oct 28, 2007 at 00:01:57 +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Sat, 27 Oct 2007, Jan Hudec wrote:
> 
> > On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:
> >
> > > ',' is allowed in ref names, so ',' is out.
> > 
> > Actually since many characters that are allowed in ref name are not 
> > allowed in URL at all, the ref-name has to be url-escaped. Which brings 
> > all characters back in, because they can always be specified escaped.
> 
> No.  The URL part of it has to be encoded.  But the ref names do _not_.  
> (If we really want to have a way to specify the remote URL and the 
> branch(es) we want to fetch _at the same time_.)

If the branch names are not url-escaped, than the result is not an URL. Which
is just ugly and confusing. If it looks like an URL, it should better be one.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: remote#branch

[Linus Torvalds]

On Mon, 29 Oct 2007, Jan Hudec wrote:
> 
> If the branch names are not url-escaped, than the result is not an URL. Which
> is just ugly and confusing. If it looks like an URL, it should better be one.

Git remote names already aren't "url"s in the http sense. 

We say "master:some.host/file/goes here/without/any/stupid/web-escapes" 
for the ssh names, and the same goes for "file:///name here" etc.

People who think that git URL's are web-pages had better wake up and smell 
the coffee. They aren't. They never were. They never *should* be.

This whole argument is idiotic. The #branch format was a mistake of 
cogito. Cogito is dead. Get over it already.

We have a format already, and it has nothing to do with '#' or any idiotic 
web escape, or anything else.

			Linus

Re: remote#branch

[Theodore Tso]

On Mon, Oct 29, 2007 at 11:17:12AM -0700, Linus Torvalds wrote:
> Git remote names already aren't "url"s in the http sense. 
> 
> We say "master:some.host/file/goes here/without/any/stupid/web-escapes" 
> for the ssh names, and the same goes for "file:///name here" etc.
> 
> People who think that git URL's are web-pages had better wake up and smell 
> the coffee. They aren't. They never were. They never *should* be.

Well, the confusion is that we refer to things that look like
"git://git.kernel.org/pub/scm/git/git.git" as if it were a URL.  In
fact, you did so yourself in the last paragraph above.  "People who
think that git URL's"....  but in fact, whether or not Universal
Resource Locators (URL's) in the RFC 3986 sense requires quoting
doesn't matter whether or not they are web pages or not.  If they are
formal URL's in the sense of RFC 3986, it doesn't matter whether they
are http URL's, or ldap URL's, or telephone URL's, etc. they are
supposed to be quoted whether or not they appear in a web form or not.
The whole point of URL's is that they are *uniform*.

So what that means is the much more correct statement is:

"People who think the names that people specify that to git, which
sometimes include names that look very much like URL's, especially
when they begin 'git://' or 'http://', and they think they are really
RFC 3986 URL's had better wake up and smell the coffee.  They aren't.
They never were.  The they never *should* be.  

The best that we can say given existing usage is that what git accepts
is a superset of what is allowable by RFC 3986 syntactically, and that
git in general doesn't do any URL-style quoting, even when given a
name that looks syntactically like a http-style URL that begins
'http://'."

What this means in practice though is that people would be well
advised not to pick locator names (NOT URL's) that contain characters
that normally would require escaping by RFC 3986 rules, since the
inconsistency of whether tools that expect URL-style quoting rules
will probably cause user and tools confusion.  Hence, it would
probably be a bad idea to place a directory pathname that included the
'#' character on a web server and expect that resulting git:// and
http:// names generated by an Apache web server and gitweb scripts to
do sane things, not to mention direct access via git:// names used
when you do a "git push" to said respository.  Sometimes the name will
require RFC 3968 quoting, and sometimes it may not be quoted using RFC
3968 rules, depending on which tool you are using.

I do agree that the Cogito '#' notation makes things worse, not
better, because it encourages a bigger separation between the RFC 3986
rules, and what the git tool accepts in practice --- which are not
URL's, no matter how much some of our git-style names superficially
look like URL's.   

							- Ted

Re: remote#branch

[Linus Torvalds]

On Mon, 29 Oct 2007, Theodore Tso wrote:
> 
> Well, the confusion is that we refer to things that look like
> "git://git.kernel.org/pub/scm/git/git.git" as if it were a URL.

Sure, but "URL" in human-speak has nothing to do with an RFC.

I dislike language-lawyerese. Why the hell do people think that human 
language should follow the RFC's?

Git addresses look like URL's, and they act like URL's, but dammit, git 
isn't a web browser, and it's not interested in acting like one. 

And "standards" are only as good as they are useful. XML is a piece of 
crap despite being a standard because it makes no sense. Similarly, "URL 
quoting" is a piece of crap when _it_ makes no sense. Having a RFC or an 
ISO standard doesn't change anything, and doesn't imply that human 
communication (or indeed, even machine communication) should care.

			Linus

Re: remote#branch

[Johannes Schindelin]

Hi,

On Mon, 29 Oct 2007, Linus Torvalds wrote:

> And "standards" are only as good as they are useful. XML is a piece of 
> crap despite being a standard because it makes no sense.

To be fair, there are uses for XML.  On Halloween, for example.

Sorry, could not resist,
Dscho

Re: remote#branch

[Theodore Tso]

On Mon, Oct 29, 2007 at 03:57:41PM -0700, Linus Torvalds wrote:
> Sure, but "URL" in human-speak has nothing to do with an RFC.
> 
> I dislike language-lawyerese. Why the hell do people think that human 
> language should follow the RFC's?
> 
> Git addresses look like URL's, and they act like URL's, but dammit, git 
> isn't a web browser, and it's not interested in acting like one. 

The quoting rules aren't specific to a web browser; the whole point of
URL's is that they are uniform so that programs know how to handle
them without needing information specific to the URL type.  Hence the
quoting rules apply to all applications using URL's, whether it's CUPS
using a url such as: ipp://example.com/printer/tiger/bob or LDAP using
a url such as: ldap://ldap.example.com/dc=example,dc=com?postalAddress.

It's just git which is different here.  Having a uniform set of
processing rules are *useful* for applications and libraries that are
parsing URL's, not just for language-lawyer wanking.  Not that git
addresses that are layered on top of http is all that well supported
any more, but in that case we really are using an http-style URL ---
but yet git doesn't do URL quoting, because, well, it doesn't.  Yet in
that case it's very clear the http address is really a URL, and it's
arguably a defect that git doesn't handle an http address the way all
other applications handle http URL's.

At the very least, if we aren't going to change git, we should hang a
big fat sign in the documentation saying that although git location
names that begin git:// look like URL's, and smell like URL's, they
aren't treated the same way that all other applications treat URL's,
and the user shouldn't be surprised by this.  Furthermore, choosing
pathnames so that git:// and gitweb http:// addresses don't require
URL-style quoting, will probably save the user a fair amount of pain
and confusion because git refuses to treat git addresses as URL's.

It would probably also be a good idea to expurgate URL's from the
documentations, because, well, they aren't URL's.  Git doesn't treat
them like URL's, and you've said you aren't interested in changing git
to treat them like URL's, and finally git:// isn't a registered URL
scheme name with the IANA registration authority.  So let's not call
them URL's, since they're clearly not.

    	      	      	  	     - Ted

Re: remote#branch

[Junio C Hamano]

Theodore Tso <tytso@mit.edu> writes:

> It would probably also be a good idea to expurgate URL's from the
> documentations, because, well, they aren't URL's.  Git doesn't treat
> them like URL's, and you've said you aren't interested in changing git
> to treat them like URL's, and finally git:// isn't a registered URL
> scheme name with the IANA registration authority.  So let's not call
> them URL's, since they're clearly not.

Are you playing reverse psychology, encouraging us to switch to
RFC-conforming quoting?

Re: remote#branch

[Theodore Tso]

On Mon, Oct 29, 2007 at 08:40:06PM -0700, Junio C Hamano wrote:
> Theodore Tso <tytso@mit.edu> writes:
> 
> > It would probably also be a good idea to expurgate URL's from the
> > documentations, because, well, they aren't URL's.  Git doesn't treat
> > them like URL's, and you've said you aren't interested in changing git
> > to treat them like URL's, and finally git:// isn't a registered URL
> > scheme name with the IANA registration authority.  So let's not call
> > them URL's, since they're clearly not.
> 
> Are you playing reverse psychology, encouraging us to switch to
> RFC-conforming quoting?

Well, URL's have a specific meaning and they're not for web browsing.
They are used to specify the addresses of printers, e-mail addresses,
LDAP servers, and much more.  Git is using something that looks like
URL's, but they they don't follow the URL rules.  So this brings up
interesting questions when a git webpage displayes something like
this (taken from repo.or.cz):

Mirror URL  git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
            http://repo.or.cz/r/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
Push URL    git+ssh://repo.or.cz/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git

Quick!  Which of the URL-like strings follow the URL quoting rules,
and which ones don't?  And if you have a character that must be quoted
in the pthname, should be quoted in in the http:// line?  And does it
matter if you are passing that URL-like string to a web browser or to
git-clone?

This is not language lawyering; this is a consistency issue that
matters.  But if Linus is going to say that git isn't going to follow
the URL quoting rules because it isn't a web browser, then clearly
what we are using aren't URL's.  So let's not *call* them URL's in our
documentation, because we're not following the URL rules.  That way is
only going to spawn more confusion.

Is this reverse psychology?  Well, I think git needs to pick whether
we operate on URL's or just things that *look* like URL's.  Either
way, the documentation should be specific about what's going on.  Me,
I'd prefer that git be liberal in what it accepts, and conservative in
what it sends.  That means that it would be useful if git could accept
URL's that are correctly quoted, and let things slide if characters
that should be quoted, aren't.  Git rarely actually emits URL's, and
mercifully people rarely use things like '#' characters in their
pathnames, so I don't think it would be that hard to make the
transition.

     	 	       	      	 	  - Ted

Re: remote#branch

[Linus Torvalds]

On Tue, 30 Oct 2007, Theodore Tso wrote:
> 
> Mirror URL  git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
>             http://repo.or.cz/r/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> Push URL    git+ssh://repo.or.cz/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git

No.

The push url is generally written as

	repo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git

Tough.

> Quick!  Which of the URL-like strings follow the URL quoting rules,
> and which ones don't?

Quick! WHO THE F*CK CARES?

		Linus

Re: remote#branch

[Tom Prince]

On Mon, Oct 29, 2007 at 09:51:47PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 30 Oct 2007, Theodore Tso wrote:
> > 
> > Mirror URL  git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> >             http://repo.or.cz/r/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> > Push URL    git+ssh://repo.or.cz/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> 
> No.
> 
> The push url is generally written as
> 
> 	repo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> 
> Tough.

But gitweb (on git.kernel.org and repo.or.cz) both give git:// locators.

> 
> > Quick!  Which of the URL-like strings follow the URL quoting rules,
> > and which ones don't?
> 
> Quick! WHO THE F*CK CARES?
> 

So, how should git deal with

git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git

compared to 

http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git

Note: this doesn't have anything to do with server:/path/to/repo

Not that I care, but git should probably handle things consistently.

  Tom

Re: remote#branch

[Linus Torvalds]

On Tue, 30 Oct 2007, Tom Prince wrote:
> > The push url is generally written as
> > 
> > 	repo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> > 
> > Tough.
> 
> But gitweb (on git.kernel.org and repo.or.cz) both give git:// locators.

Yes, for anonymous pulling.

The thing is, git takes something much more extended than a "RFC url".

We use pathnames. Not a "quoted mess". Regular, bog-standard, normal unix 
pathnames.

On Windows, I assume (and hope) that git uses the native-style Windows 
pathnames, and you can do "git pull d:\system\ugh" if you want to.

And I think we should care a whole lot about interacting with the *user* 
and actual programs that git shares code with, than interacting with some 
idiotic RFC that has absolutely zero to do with us, regardless of whether 
we use the name "url" or not.

For example, the reason we use "host:/path" for pushing over ssh (and 
pulling, for that matter), is that that's the same syntax that scp uses. 
It's a natural fit. And I hope to God nobody seriously argues that we 
shouldn't use regular pathnames on the local disk? 

> > Quick! WHO THE F*CK CARES?

[ Btw, sorry for the french. I blame being tired and ina bad mood, but I 
  also blame the fact that I absolutely *detest* arguments based on 
  standards. If you cannot back it up with a real usage scenario, you 
  shouldn't even mention the standard ]

> So, how should git deal with
> 
> git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git

The way it has always cared. Git itself does no quoting what-so-ever 
(except for the *argument* quoting etc that it needs).

Now, the *transport* back-end may end up quoting it, of course, the same 
way it may end up using some random protocol. The user shouldn't care 
about the implementation details!

In the case of the git transport, there is no quoting even by the 
transport protocol. In the case of http, libcurl would hopefully quote for 
us.

> compared to 
> 
> http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git

No difference, what-so-ever, that I can see. Git doesn't quote it.

Notice how the fact that we use http:// doesn't actually mean that you can 
feed the result to a web browser anyway? It's not like you get a "link" 
that git follows. You get a name.

Yes, you can try to "co-locate" things so that something smart 
disambiguates (maybe have an "index.html" file, so a web browser gets a 
gitweb page, and git gets the raw data). But even then, notice how even 
web browser will do the quoting for you: try

	firefox "http://www.google.com/search?q=Html spaces"

just for fun.

Notice? The thing is, "strict RFC following" makes no sense:

 - the git syntax is (and HAS TO BE to be user friendly) a real extension 
   on any "strict RFC URL" anyway, since it is a lot more important to 
   interact well with normal unix tools (ie use regular filenames, and use 
   the same syntax as "cp", "mv" and "find" etc uses!)

   Ergo: we cannot and MUST NOT care about the "URL RFC" too deeply 
   anyway.

 - 

> Not that I care, but git should probably handle things consistently.

Git has been, and *is* entirely consistent. It uses convenient repo names. 
If you don't want to call them url's, then call them "repository name". 
Call them whatever. But they are 100% obvious, even if there are multiple 
forms of them (and *none* of the forms do any quoting at all):

 - <remote shorthand> ("origin")
 - <path> ("../git.git")
 - <host>:<path> ("master.kernel.org:/pub/scm/...")
 - <protocol>://<host>/<path> ("git://repo.or.cz/...")

See? We may not follow RFC's, but we follow "easy to use".

And btw, that's really much much MUCH more important. It's why the git 
config file is in a "ini"-like format. It's readable. It's not the insane 
RFC crap that would result if somebody had decided that standards are more 
important than being sane.

			Linus

Re: remote#branch

[Tom Prince]

On Tue, Oct 30, 2007 at 07:59:45AM -0700, Linus Torvalds wrote:
> > Not that I care, but git should probably handle things consistently.
> 
> Git has been, and *is* entirely consistent. It uses convenient repo names. 
> If you don't want to call them url's, then call them "repository name". 
> Call them whatever. But they are 100% obvious, even if there are multiple 
> forms of them (and *none* of the forms do any quoting at all):
> 
>  - <remote shorthand> ("origin")
>  - <path> ("../git.git")
>  - <host>:<path> ("master.kernel.org:/pub/scm/...")
>  - <protocol>://<host>/<path> ("git://repo.or.cz/...")
> 
> See? We may not follow RFC's, but we follow "easy to use".

Well, only the last one actually looks like a URL, so that is the only this
discussion is about. I don't think anyone is suggesting that the first three
be changed at all. So, to use your terminology, git has a variety of ways to
specify a repo name, one of which happens to be a URL (or looks like one). The
suggestion is that we should make that way (and only that way) behave like a
RFC URL.

And git should be consistent with web browsers, automatically quoting things
it gets passed. I think the only point of contention is probably how to deal
with URLs that git receives that are already quoted.

1. We ignore the quoting and re-encode everything for the http transport.
2. We honour the encoding and decode everything for the git transport.
3. We handle git:// and http:// different, so that the three git:// URLs below
refer to different repositories, while the three http:// URLs give refer to
the same repository.

> > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
> 
> > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git

The third possibility is probably what we do now, which is why I am suggesting
git is inconsistent. The first will fall down when using a repository that is
colocated, and somebody copies a URL from the web browsers location bar (which
will be properly encoded). Which leaves the second.

  Tom

Re: remote#branch

[Linus Torvalds]

On Tue, 30 Oct 2007, Tom Prince wrote:
> >
> >  - <remote shorthand> ("origin")
> >  - <path> ("../git.git")
> >  - <host>:<path> ("master.kernel.org:/pub/scm/...")
> >  - <protocol>://<host>/<path> ("git://repo.or.cz/...")
> >
> > See? We may not follow RFC's, but we follow "easy to use".
>
> Well, only the last one actually looks like a URL, so that is the only this
> discussion is about.

NO.

The thing is, we'd be much better off being consistent with OURSELVES than
with something else!

Nobody cares about git being consistent with a web browser. There is
nothing in common.

But I *do* care about git being consistent with itself. If I do

	git clone /some/directory

and then decide that I want to generate a new pack and change it into

	git clone file:///some/directory

I don't want to have to re-write the thing to quote differently!

The same very much goes for a path like

	git://git.kernel.org/<path>

vs

	master.kernel.org:<path>

because I will use the two interchangably. They *are* the same address,
except:

 - the "git://" protocol is a bit faster, since the ssh connection
   overhead is actually big enough to be quite noticeable.

 - but I often use the master.kernel.org:<path> thing because there's a
   mirroring delay that means that accessing it directly is sometimes
   preferable.

See? THAT is where we need to be consistent: with our own paths!

[ And yes, I literally really do switch things around exactly like that 
  between ssh accesses and the git:// protocol. That was not a made-up 
  example, but real usage! ]

In contrast, nobody has _ever_ given a real technical reason to care about
the Web URL RFC at all.

Really. It's that simple: if you cannot argue for something without
pointing to an irrelevant standard, you really shouldn't argue for it in
the first place.

People who make decisions based on "it's a standard" make *sub*standard
decisions. The fact is, most standards are not worth even using as toilet
paper, because they were designed by some committee that wanted to reach
"consensus". That's just crap.

                        Linus

Re: remote#branch

[Matthieu Moy]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Nobody cares about git being consistent with a web browser.

Why do you keep talking about web browser?

URLs are _not_ a web-browser thing. A web browser is just _one_
example of program which uses URLs.

-- 
Matthieu

Re: remote#branch

[Linus Torvalds]

On Tue, 30 Oct 2007, Matthieu Moy wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > Nobody cares about git being consistent with a web browser.
> 
> Why do you keep talking about web browser?
> 
> URLs are _not_ a web-browser thing. A web browser is just _one_
> example of program which uses URLs.

I keep talking about a web browser, because THE ONLY POINT of following a 
standard is to interoperate.

So if you cannot find something to interoperate with, why the hell would 
you care about the standard?

So here's a question: why do people bother to quote irrelevant RFC's?

Following those RFC's would make git not interoperate WITH ITSELF, and use 
illogically different formats for the same things.

So if you want to make that RFC have any relevance what-so-ever, then show 
some interoperability issue. Which is why I'm bringing up a web browser: 
that interop issue simply *does*not*exist*.

Why is that so hard to understand?

			Linus

Re: remote#branch

[Linus Torvalds]

On Tue, 30 Oct 2007, Linus Torvalds wrote:
> 
> So if you want to make that RFC have any relevance what-so-ever, then show 
> some interoperability issue. Which is why I'm bringing up a web browser: 
> that interop issue simply *does*not*exist*.

Btw, the reason I care is that the whole ".. but it's a standard" thinking 
really is dangerous. It's how you create absolute and utter crap.

It's why I have also brought up XML in this discussion, because XML is a 
classic example of something where this ".. but it's a standard" thinking 
has resulted in really bad solutions. It's pushed as a way to 
"interoperate", but then, since everybody does different things, the only 
thing you can actually interoperate with is by having a common parsing 
library for a REALLY HORRIBLY BAD FORMAT!

The same is true of a URL. What is there to interoperate with? The whole 
(and only) point of the git remote URL is to point git to a different git 
repository. There's no other reason to use it. So the only possible case 
we care about interoperability is with other git uses.

And those other git uses are not RFC1738-quoted, are they? 

			Linus

Re: remote#branch

[Pascal Obry]

Linus Torvalds a écrit :
> I keep talking about a web browser, because THE ONLY POINT of following a 
> standard is to interoperate.

Yes, and since URLs are not used for web browser only I do not see the
point to concentrate all this discussion about a single possible usage.

> Why is that so hard to understand?

I'm thinking alike :)

Pascal;

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: remote#branch

[Linus Torvalds]

On Tue, 30 Oct 2007, Pascal Obry wrote:

> Linus Torvalds a écrit :
> > I keep talking about a web browser, because THE ONLY POINT of following a 
> > standard is to interoperate.
> 
> Yes, and since URLs are not used for web browser only I do not see the
> point to concentrate all this discussion about a single possible usage.

Hey, it's find if you can come up with some *other* case why we should 
care about RFC 1738.

I certainly didn't mean to bring up browsers as the _only_ case of 
possible interoperability issues, but when it comes to URL's it's 
certainly the obvious one...

So the only argument really is:

 - Nobody has pointed to *any* reason to follow 1738.

 - I have pointed to reasons *not* to do it.

So if you want to follow the RFC, you'd better give a real reason. And no, 
the existence of an RFC, and the fact that people use the same name for 
things that superficially _look_ the same is not a reason in itself.

So hands up, people. Anybody who asked for RFC quoting. Give a damn 
*reason* already!

			Linus

Re: remote#branch

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:

Linus> So the only argument really is:

Linus>  - Nobody has pointed to *any* reason to follow 1738.

Linus>  - I have pointed to reasons *not* to do it.

I can support non-compliance with 1738.  However, I'd also suggest
that outside of this cozy group of developers, URL already has a heavily
defined meaning associated with 1738.

Therefore, I propose that the git docs refrain from calling these things
"URLs" because they're not, and instead adopt something like "GRL" (git
resources locator) or whatever.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: remote#branch

[Linus Torvalds]

On Tue, 30 Oct 2007, Randal L. Schwartz wrote:
> 
> Therefore, I propose that the git docs refrain from calling these things
> "URLs" because they're not, and instead adopt something like "GRL" (git
> resources locator) or whatever.

They're called "GIT URLS" right now. I'd have hoped that was descriptive 
enough. But maybe not.

I think it's stupid to make up a new name, it's not like it's really 
ambiguous *or* as if people really think in terms of RFC's.

Let's face it: people talk and use email, even when they don't have a clue 
about SMTP. And in practice, you'll never see any difference, apart from 
the obvious extension of using the ssh format and the direct local path 
thing.

		Linus

Re: remote#branch

[Nicolas Pitre]

On Tue, 30 Oct 2007, Randal L. Schwartz wrote:

> >>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> Linus> So the only argument really is:
> 
> Linus>  - Nobody has pointed to *any* reason to follow 1738.
> 
> Linus>  - I have pointed to reasons *not* to do it.
> 
> I can support non-compliance with 1738.  However, I'd also suggest
> that outside of this cozy group of developers, URL already has a heavily
> defined meaning associated with 1738.
> 
> Therefore, I propose that the git docs refrain from calling these things
> "URLs" because they're not, and instead adopt something like "GRL" (git
> resources locator) or whatever.

And what do you do with the remote.<name>.url config option?
Add some backward compatibility cruft for some... well... issue that 
turns out not to be one in practice?

Again, can someone point to a real usage scenario where all this 
discussion is solving something?


Nicolas

Re: remote#branch

[Jeff King]

On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:

> So if you want to follow the RFC, you'd better give a real reason. And no, 
> the existence of an RFC, and the fact that people use the same name for 
> things that superficially _look_ the same is not a reason in itself.
> 
> So hands up, people. Anybody who asked for RFC quoting. Give a damn 
> *reason* already!

I didn't ask for RFC quoting, but a nice side effect of URL syntax is
that they are machine parseable. If you wanted to write a tool to pick
the URLs out of this email and clone them as git repos, then how do you
find the end of:

  http://host/git repo with spaces in the path

compared to:

  http://host/git+repo+with+spaces+in+the+path

I don't know if that's worth changing anything in git (in fact, I'm not
even clear on _what_ people want to change; the point of this discussion
seems to be to argue about terminology). But you did ask for any reason
for quoting URLs.

-Peff

Re: remote#branch

[Jakub Narebski]

Jeff King wrote:

> On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:
> 
>> So if you want to follow the RFC, you'd better give a real reason. And no, 
>> the existence of an RFC, and the fact that people use the same name for 
>> things that superficially _look_ the same is not a reason in itself.
>> 
>> So hands up, people. Anybody who asked for RFC quoting. Give a damn 
>> *reason* already!
> 
> I didn't ask for RFC quoting, but a nice side effect of URL syntax is
> that they are machine parseable. If you wanted to write a tool to pick
> the URLs out of this email and clone them as git repos, then how do you
> find the end of:
> 
>   http://host/git repo with spaces in the path
> 
> compared to:
> 
>   http://host/git+repo+with+spaces+in+the+path
> 
> I don't know if that's worth changing anything in git (in fact, I'm not
> even clear on _what_ people want to change; the point of this discussion
> seems to be to argue about terminology). But you did ask for any reason
> for quoting URLs.

You use

  'http://host/git repo with spaces in the path'

Theoretically, we can follow what other CLI tools dealing with URLs do
(like wget, lynx, ...), i.e. assume that URL is _not_ RFC-escaped if it
is in quotes, and assume that URL is properly escaped if it is not quoted.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: remote#branch

[Jeff King]

On Wed, Oct 31, 2007 at 01:12:37AM +0100, Jakub Narebski wrote:

> > that they are machine parseable. If you wanted to write a tool to pick
> > the URLs out of this email and clone them as git repos, then how do you
> > find the end of:
> > 
> >   http://host/git repo with spaces in the path
> You use
> 
>   'http://host/git repo with spaces in the path'

...which is a quoting mechanism, and it's not even one commonly used in
emails (i.e., people have written "parse a URL from this text" scripts
for RFC-encoded URLs, but _not_ for shell quoting).

-Peff

Re: remote#branch

[Jakub Narebski]

Jeff King wrote:
> On Wed, Oct 31, 2007 at 01:12:37AM +0100, Jakub Narebski wrote:
> 
>>> that they are machine parseable. If you wanted to write a tool to pick
>>> the URLs out of this email and clone them as git repos, then how do you
>>> find the end of:
>>> 
>>>   http://host/git repo with spaces in the path
>>
>> You use
>> 
>>   'http://host/git repo with spaces in the path'
> 
> ...which is a quoting mechanism, and it's not even one commonly used in
> emails (i.e., people have written "parse a URL from this text" scripts
> for RFC-encoded URLs, but _not_ for shell quoting).

I don't think RFC-encoding is quoting mechanism used in emails, either.

-- 
Jakub Narebski
Poland

Re: remote#branch

[Jeff King]

On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:

> > ...which is a quoting mechanism, and it's not even one commonly used in
> > emails (i.e., people have written "parse a URL from this text" scripts
> > for RFC-encoded URLs, but _not_ for shell quoting).
> 
> I don't think RFC-encoding is quoting mechanism used in emails, either.

That's funny, because I have hundreds of mails where that is the case,
and none where people used shell-quoting.  Most URLs don't _need_ any
encoding, so we don't notice either way. But are you honestly telling me
that if you needed to communicate a URL with a space via email, you
would write:

  'http://foo.tld/url with a space'

rather than:

  http://foo.tld/url+with+a+space

?

I think the latter is much more common, if only because of the fact that
copy and paste from most browsers' location bars gives the encoded
version.

-Peff

Re: remote#branch

[Andreas Ericsson]

Jeff King wrote:
> On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:
> 
>>> ...which is a quoting mechanism, and it's not even one commonly used in
>>> emails (i.e., people have written "parse a URL from this text" scripts
>>> for RFC-encoded URLs, but _not_ for shell quoting).
>> I don't think RFC-encoding is quoting mechanism used in emails, either.
> 
> That's funny, because I have hundreds of mails where that is the case,
> and none where people used shell-quoting.  Most URLs don't _need_ any
> encoding, so we don't notice either way. But are you honestly telling me
> that if you needed to communicate a URL with a space via email, you
> would write:
> 
>   'http://foo.tld/url with a space'
> 
> rather than:
> 
>   http://foo.tld/url+with+a+space
> 
> ?
> 

I think 99% of all URL's communicated via email are copy-pasted from a
webbrowsers location bar. I believe most git urls (or grls, or whatever
you wanna call them) communicated via email are copy-pasted from ones
config, or written out manually.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: remote#branch

[Mike Hommey]

On Wed, Oct 31, 2007 at 08:09:01AM +0100, Andreas Ericsson <ae@op5.se> wrote:
> Jeff King wrote:
> >On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:
> >
> >>>...which is a quoting mechanism, and it's not even one commonly used in
> >>>emails (i.e., people have written "parse a URL from this text" scripts
> >>>for RFC-encoded URLs, but _not_ for shell quoting).
> >>I don't think RFC-encoding is quoting mechanism used in emails, either.
> >
> >That's funny, because I have hundreds of mails where that is the case,
> >and none where people used shell-quoting.  Most URLs don't _need_ any
> >encoding, so we don't notice either way. But are you honestly telling me
> >that if you needed to communicate a URL with a space via email, you
> >would write:
> >
> >  'http://foo.tld/url with a space'
> >
> >rather than:
> >
> >  http://foo.tld/url+with+a+space
> >
> >?
> >
> 
> I think 99% of all URL's communicated via email are copy-pasted from a
> webbrowsers location bar. I believe most git urls (or grls, or whatever
> you wanna call them) communicated via email are copy-pasted from ones
> config, or written out manually.

Or copied from gitweb.

Mike

Re: remote#branch

[Andreas Ericsson]

Mike Hommey wrote:
> On Wed, Oct 31, 2007 at 08:09:01AM +0100, Andreas Ericsson <ae@op5.se> wrote:
>> Jeff King wrote:
>>> On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:
>>>
>>>>> ...which is a quoting mechanism, and it's not even one commonly used in
>>>>> emails (i.e., people have written "parse a URL from this text" scripts
>>>>> for RFC-encoded URLs, but _not_ for shell quoting).
>>>> I don't think RFC-encoding is quoting mechanism used in emails, either.
>>> That's funny, because I have hundreds of mails where that is the case,
>>> and none where people used shell-quoting.  Most URLs don't _need_ any
>>> encoding, so we don't notice either way. But are you honestly telling me
>>> that if you needed to communicate a URL with a space via email, you
>>> would write:
>>>
>>>  'http://foo.tld/url with a space'
>>>
>>> rather than:
>>>
>>>  http://foo.tld/url+with+a+space
>>>
>>> ?
>>>
>> I think 99% of all URL's communicated via email are copy-pasted from a
>> webbrowsers location bar. I believe most git urls (or grls, or whatever
>> you wanna call them) communicated via email are copy-pasted from ones
>> config, or written out manually.
> 
> Or copied from gitweb.
> 

Perhaps, but I've never seen that done. Partly because you can't be sure
the HTTP url is the same as the git address (perhaps people are used to
this from CVS and the likes), and partly because you'd, for most cases,
want to use git:// or ssh transport instead of http.

It might be nifty to have gitweb print some git-valid locator for a repo
though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
command-line thingie. I'll look into it when I have leisure.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: remote#branch

[Mike Hommey]

On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson <ae@op5.se> wrote:
> >Or copied from gitweb.
> >
> 
> Perhaps, but I've never seen that done. Partly because you can't be sure
> the HTTP url is the same as the git address (perhaps people are used to
> this from CVS and the likes), and partly because you'd, for most cases,
> want to use git:// or ssh transport instead of http.
> 
> It might be nifty to have gitweb print some git-valid locator for a repo
> though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
> command-line thingie. I'll look into it when I have leisure.

Hum... it already does print http and git "Mirror URL"s which are ready to
be copy/pasted to feed git clone arguments.

Mike

Re: remote#branch

[Jakub Narebski]

Mike Hommey wrote:
> On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson <ae@op5.se> wrote:
>>>
>>>Or copied from gitweb.
>>>
>> Perhaps, but I've never seen that done. Partly because you can't be sure
>> the HTTP url is the same as the git address (perhaps people are used to
>> this from CVS and the likes), and partly because you'd, for most cases,
>> want to use git:// or ssh transport instead of http.
>> 
>> It might be nifty to have gitweb print some git-valid locator for a repo
>> though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
>> command-line thingie. I'll look into it when I have leisure.
> 
> Hum... it already does print http and git "Mirror URL"s which are ready to
> be copy/pasted to feed git clone arguments.

The only thing to add (for absolutely no gain IMHO) would be code
which would add quotes (single or double) around URL/path which
contain spaces:
  
  Mirror URL    'git://repo.or.cz/repo with spaces.git'
                'http://repo.or.cz/r/repo with spaces.git'
  Push URL      'repo.or.cz:/srv/git/repo with spaces.git'  

-- 
Jakub Narebski
Poland

Re: remote#branch

[Theodore Tso]

On Thu, Nov 01, 2007 at 01:22:33AM +0100, Jakub Narebski wrote:
> The only thing to add (for absolutely no gain IMHO) would be code
> which would add quotes (single or double) around URL/path which
> contain spaces:
>   
>   Mirror URL    'git://repo.or.cz/repo with spaces.git'
>                 'http://repo.or.cz/r/repo with spaces.git'
>   Push URL      'repo.or.cz:/srv/git/repo with spaces.git'  

The one thing that I think might be worth doing out of all of this is
to add code to git so that it can accept URL quoted arguments.  Given
that it's highly unlikely anyone is using repository pathnames that
contain the '%' character, this would be highly unlikely to cause any
backwards compatibility problems.

					- Ted

Re: remote#branch

[Andreas Ericsson]

Mike Hommey wrote:
> On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson <ae@op5.se> wrote:
>>> Or copied from gitweb.
>>>
>> Perhaps, but I've never seen that done. Partly because you can't be sure
>> the HTTP url is the same as the git address (perhaps people are used to
>> this from CVS and the likes), and partly because you'd, for most cases,
>> want to use git:// or ssh transport instead of http.
>>
>> It might be nifty to have gitweb print some git-valid locator for a repo
>> though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
>> command-line thingie. I'll look into it when I have leisure.
> 
> Hum... it already does print http and git "Mirror URL"s which are ready to
> be copy/pasted to feed git clone arguments.
> 

True that. I went looking for such an option a long time ago and didn't find
it. I should do my research better.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: remote#branch

[Pascal Obry]

Jeff King a écrit :
>   'http://foo.tld/url with a space'
> 
> rather than:
> 
>   http://foo.tld/url+with+a+space
> 
> ?
> 
> I think the latter is much more common, if only because of the fact that
> copy and paste from most browsers' location bars gives the encoded
> version.

I agree 100%. It is the more common as it follows the standard encoding.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: remote#branch

[David Kastrup]

Jakub Narebski <jnareb@gmail.com> writes:

> Jeff King wrote:
>
>> On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:
>> 
>>   http://host/git repo with spaces in the path
>> 
>> compared to:
>> 
>>   http://host/git+repo+with+spaces+in+the+path
>> 
>> I don't know if that's worth changing anything in git (in fact, I'm not
>> even clear on _what_ people want to change; the point of this discussion
>> seems to be to argue about terminology). But you did ask for any reason
>> for quoting URLs.
>
> You use
>
>   'http://host/git repo with spaces in the path'

I can click on links in my mail reader, and the above is not recognized
as one.  <URL:http://host/git repo with spaces in the path> would likely
work.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: remote#branch

[Linus Torvalds]

On Wed, 31 Oct 2007, David Kastrup wrote:
> 
> I can click on links in my mail reader, and the above is not recognized
> as one.  <URL:http://host/git repo with spaces in the path> would likely
> work.

I don't think this whole discussion is relevant at all.

Why?

Because we don't care! This is *exactly* why I brought up the whole 
discussion about "interoperability with a web browser", and pointed out 
that there is no such thing *anyway*, since a GIT URL is generally not 
suitable for browsing _regardless_ of any encoding issues!

So it doesn't matter one whit if a mail client recognizes GIT URL's or 
not! Because the mail client cannot do the right thing with them anyway, 
and would generally think that it's something that it should highlight so 
that you can browse it!

Besides, you generally shouldn't use http for git URL's in the first 
place, and they are very much a secondary citizen. Yes, some people use 
them because they have firewall issues, and they *work*, but giving them 
as examples of GIT URL's and discussing them as it they were a big deal is 
just *stupid* when no other - more realistic - git url works that way 
anyway.

This was the whole and only point of my "interoperability" thing. The GIT 
URL's - even when they are perfectly well-formed URL's (which is basically 
100% of the time, since no current git server tends to put things like 
spaces in the path anyway) - are simply in a different "space" than most 
other URL's.

You cannot feed them to a web browser or a file browser anyway, since the 
URL is actually mal-formed (on purpose) in *another* and more fundamental 
way: it doesn't say what the "application domain" is, since it basically 
just assumes that the application domain is git, and the "scheme" part of 
the URL really talks only about the _protocol_, not about the fact that 
it's a git thing.

So if you wanted to be inter-operable, you'd have add the "git" part to 
the scheme, and do the (insane, in my opinion) cogito thing with 
"git+http://xyz.hjashja/" thing!

See? Otherwise no non-git program could understand *anyway* that it's a 
git address, and not meant to be some html thing.

So to summarise:

 - the only way to make git interoperate would be to be user-UNfriendly 
   with stupid markers that no git program really needs or wants, and by 
   making the escaping depend on the form of the GIT URL.

But hey, if people want to screw up git even more, and make the "git+" 
crap also encode the address, I don't care. I would never *ever* use the 
"git+xyz://" forms anyway. They're stupid and useless, but if you want to 
have programs automatically do something magical about git url's, you'd 
need that "git+" thing.

Personally, I think it's a much better idea to just be git-specific. 
Because realistically, nobody is ever going to really be anything else 
anyway. There is nothing you can sanely do with a git link, unless it's 
something very git specific and conscious in the first place!

			Linus

Re: remote#branch

[Jeff King]

On Wed, Oct 31, 2007 at 08:28:36AM -0700, Linus Torvalds wrote:

> Because we don't care! This is *exactly* why I brought up the whole 
> discussion about "interoperability with a web browser", and pointed out 
> that there is no such thing *anyway*, since a GIT URL is generally not 
> suitable for browsing _regardless_ of any encoding issues!
> 
> So it doesn't matter one whit if a mail client recognizes GIT URL's or 
> not! Because the mail client cannot do the right thing with them anyway, 
> and would generally think that it's something that it should highlight so 
> that you can browse it!

Two points:

 1. Just because _your_ mail client can't do anything useful with git
    URLs^H^H^H^H repo specifications, doesn't mean that others can't.

 2. You are conflating syntax and semantics. Think of the task I
    mentioned as two subtasks: pulling the location specifier from the
    email, and then doing something useful with it (in this case,
    git-cloning it it). The first subtask depends _only_ on a parseable
    syntax. The user can provide the context necessary for accomplishing
    the second subtask.

For example, consider a terminal that, upon pressing some keyboard
combination, will highlight the first URL-ish looking blob on the
screen, prompt you for a command, and then execute '$command $url'.  The
terminal doesn't have to know the semantics of the blob, but it has to
know the syntax. The user provides the semantics.

And yes, such a terminal exists, and I'm using it right now.

> Besides, you generally shouldn't use http for git URL's in the first 
> place, and they are very much a secondary citizen. Yes, some people use 
> them because they have firewall issues, and they *work*, but giving them 
> as examples of GIT URL's and discussing them as it they were a big deal is 
> just *stupid* when no other - more realistic - git url works that way 
> anyway.

The example above is equally applicable to git:// URLs. As it is to
host:path specifiers, although obviously that is a syntax that the
highlighter would have to recognize. But the point is that by following
established syntaxes, you don't have to write a git-repo-specifier
syntax parser; it comes for free (and isn't that, after all, the entire
_point_ of URLs?).

> This was the whole and only point of my "interoperability" thing. The GIT 
> URL's - even when they are perfectly well-formed URL's (which is basically 
> 100% of the time, since no current git server tends to put things like 
> spaces in the path anyway) - are simply in a different "space" than most 
> other URL's.

Sure, you need context to use them correctly. But that doesn't
necessarily mean you should just give up on the syntax part. I would
rather the computer do half of the task and let me finish it than make
me do the whole thing.

> You cannot feed them to a web browser or a file browser anyway, since the 
> URL is actually mal-formed (on purpose) in *another* and more fundamental 
> way: it doesn't say what the "application domain" is, since it basically 
> just assumes that the application domain is git, and the "scheme" part of 
> the URL really talks only about the _protocol_, not about the fact that 
> it's a git thing.
> 
> So if you wanted to be inter-operable, you'd have add the "git" part to 
> the scheme, and do the (insane, in my opinion) cogito thing with 
> "git+http://xyz.hjashja/" thing!

Yes, if you did that, you could automate _both_ parts of the task. But
again, that doesn't mean there isn't value to automating the first part
But that aside, even git+http doesn't solve all of your problems,
because it doesn't say _what_ you want to do with the location. Web
browsers just assume you want to fetch and view a location. But other
tools which accept URLs might perform _other_ actions on a given
location. So URLs really are a "subject" that can be operated on. It's
just that we are most accustomed to seeing them used by the "retrieve
this and display it" tool.

>  - the only way to make git interoperate would be to be user-UNfriendly 
>    with stupid markers that no git program really needs or wants, and by 
>    making the escaping depend on the form of the GIT URL.

Some git specifiers clearly look like URLs. Why not accept URL encoding
for them? And if there are characters that _should_ have been encoded by
URL encoding standards, treat them as if they had been encoded (i.e.,
handing 'http://foo.tld/repo with space' would be treated the same as
'http://foo.tld/repo%20with%20space'). This means that most unencoded
repos will behave exactly the same, but we are more liberal in wht we
accept. The exception is that repos with a '%' in the specifier will
parse differently (i.e., if you actually had a repo with the literal
characters '%20' in it, it will no parse).

Yes, this means that if you have a bizarre repo name, you can't
necessarily switch between host:file syntax and git:// syntax by simple
cut and paste. But you really can't _anyway_, since there is no
guarantee that they are rooted at the same location, or have the same
view of the filesystem.

> Personally, I think it's a much better idea to just be git-specific. 

Then why in the world did you choose a specifier syntax that looks
_exactly_ like a URL?

-Peff

Re: remote#branch

[Linus Torvalds]

On Wed, 31 Oct 2007, Jeff King wrote:
> 
> Yes, this means that if you have a bizarre repo name, you can't
> necessarily switch between host:file syntax and git:// syntax by simple
> cut and paste. But you really can't _anyway_, since there is no
> guarantee that they are rooted at the same location, or have the same
> view of the filesystem.

.. but in practice it works fine, especially for something like kernel.org 
where it really *is* the same filesystem, just mirrored out.

Also, more importantly, I think the quoting is *stupid*. It adds pointless 
code for absolutely zero gain. Are you going to unquote '/'? Or how about 
'~'?

It's much nicer to just not have the quoting issue at all. Repo names are 
names. Straight up.

> > Personally, I think it's a much better idea to just be git-specific. 
> 
> Then why in the world did you choose a specifier syntax that looks
> _exactly_ like a URL?

.. because it's a simple format, and it *works*. The same way INI config 
files are simple and *work*.

And because I didn't think I'd have to care about people who like f*cking 
around with idiotic details, rather than just get something that is useful 
and works!

If you don't like the fact that git doesn't quote, just don't use the 
magic characters. It's that easy. And if somebody quotes the '/', just 
tell him off for being an ass.

But git can and should do the *sane* thing.

			Linus

Re: remote#branch

[Jeff King]

On Wed, Oct 31, 2007 at 02:01:54PM -0700, Linus Torvalds wrote:

> > Yes, this means that if you have a bizarre repo name, you can't
> > necessarily switch between host:file syntax and git:// syntax by simple
> > cut and paste. But you really can't _anyway_, since there is no
> > guarantee that they are rooted at the same location, or have the same
> > view of the filesystem.
> 
> .. but in practice it works fine, especially for something like kernel.org 
> where it really *is* the same filesystem, just mirrored out.

Yes, and in practice, it works with or without URL encoding, since
people aren't using names that need encoded.

> Also, more importantly, I think the quoting is *stupid*. It adds pointless 
> code for absolutely zero gain. Are you going to unquote '/'? Or how about 
> '~'?

I don't think it's zero gain; I think it's exactly what users who use
repos with characters that need quoting will expect to happen. That
being said, _I_ don't personally care that much since I think spaces in
filenames are the work of the devil, and I will never use them. And as a
result, I'm not going to implement the code to do it.

But I do think your argument that there is no value in the URL syntax is
just wrong.

I don't understand your mention of '~' and '/'; they don't need quoted
in URLs, and generally are not (though of course they can be).

> .. because it's a simple format, and it *works*. The same way INI config 
> files are simple and *work*.

But if you wrote a bunch of documentation referring to the git config
file as an INI file, would you expect people to complain when it
_didn't_ follow the usual expectation for INI files?


OK, this discussion is just getting nowhere, and there is useful git
work I could be doing, so let me sum up my position:

  - We should either resolve that some repo specifiers are URLs, or we
    should resolve that they are not. I think they are.
  - If they are URLs, then we should treat them like URLs, and not
    handling quoting is probably a bug. I refuse to accept that it is an
    _important_ bug until somebody actually has a repo that needs
    quoting, finds that git is substandard, and provides a patch.
  - If they are not URLs, then we should probably stop calling them that
    in the documentation.

And with that, I shall say no more on the subject. In the spirit of not
saying "oh, I don't want to talk about it anymore, you don't get to say
anything else," I invite you to respond to any of my comments above.

-Peff

Re: remote#branch

[Linus Torvalds]

On Wed, 31 Oct 2007, Linus Torvalds wrote:
> 
> If you don't like the fact that git doesn't quote, just don't use the 
> magic characters. It's that easy. And if somebody quotes the '/', just 
> tell him off for being an ass.

Side note - none of the repos I use are likely to actually have any 
quoting as an issue, so in that sense I don't actually care. I'd never 
notice if git did any quoting or not.

What I care about - and where I entered the discussion - is that the real 
impetus for this *stupid* quoting is not the actual need for quoting in 
itself (which doesn't seem to exist), but because people want to extend 
the repository naming to contain other things too, in particular the 
broken cogito single-branch naming thing.

So I could care less about some detail that I'll never even notice, if it 
wasn't for the fact that there's all this other baggage that goes with 
this whole thing. So the quoting itself is more of a symptom of the real 
problem.

Guess what? I didn't make the config file follow any Windows INI standards 
either. I'm just waiting for the first person to point out that you cannot 
parse a .gitconfig file with standard INI parsers.

			Linus

Re: remote#branch

[Andreas Ericsson]

Jeff King wrote:
> On Wed, Oct 31, 2007 at 08:28:36AM -0700, Linus Torvalds wrote:
> 
>> Because we don't care! This is *exactly* why I brought up the whole 
>> discussion about "interoperability with a web browser", and pointed out 
>> that there is no such thing *anyway*, since a GIT URL is generally not 
>> suitable for browsing _regardless_ of any encoding issues!
>>
>> So it doesn't matter one whit if a mail client recognizes GIT URL's or 
>> not! Because the mail client cannot do the right thing with them anyway, 
>> and would generally think that it's something that it should highlight so 
>> that you can browse it!
> 
> Two points:
> 
>  1. Just because _your_ mail client can't do anything useful with git
>     URLs^H^H^H^H repo specifications, doesn't mean that others can't.
> 
>  2. You are conflating syntax and semantics. Think of the task I
>     mentioned as two subtasks: pulling the location specifier from the
>     email, and then doing something useful with it (in this case,
>     git-cloning it it). The first subtask depends _only_ on a parseable
>     syntax. The user can provide the context necessary for accomplishing
>     the second subtask.
> 
> For example, consider a terminal that, upon pressing some keyboard
> combination, will highlight the first URL-ish looking blob on the
> screen, prompt you for a command, and then execute '$command $url'.  The
> terminal doesn't have to know the semantics of the blob, but it has to
> know the syntax. The user provides the semantics.
> 
> And yes, such a terminal exists, and I'm using it right now.
> 

Great. Now you just need a git-repo with an url that needs quoting, and
this discussion could at least potentially solve a real problem for someone.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: remote#branch

[Jeff King]

On Wed, Oct 31, 2007 at 10:07:33PM +0100, Andreas Ericsson wrote:

> Great. Now you just need a git-repo with an url that needs quoting, and
> this discussion could at least potentially solve a real problem for someone.

I would make one on repo.or.cz just to spite you, but it refuses to
create repos with exotic characters in the name.

-Peff

P.S. I agree with your point.

Re: remote#branch

[David Kastrup]

Jeff King <peff@peff.net> writes:

> On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:
>
>> So if you want to follow the RFC, you'd better give a real reason. And no, 
>> the existence of an RFC, and the fact that people use the same name for 
>> things that superficially _look_ the same is not a reason in itself.
>> 
>> So hands up, people. Anybody who asked for RFC quoting. Give a damn 
>> *reason* already!
>
> I didn't ask for RFC quoting, but a nice side effect of URL syntax is
> that they are machine parseable. If you wanted to write a tool to pick
> the URLs out of this email and clone them as git repos, then how do you
> find the end of:
>
>   http://host/git repo with spaces in the path
>
> compared to:
>
>   http://host/git+repo+with+spaces+in+the+path

You just write <URL:http://host/git repo with spaces in the path> and
have a good chance it will work.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: remote#branch

[Wincent Colaiuta]

El 31/10/2007, a las 7:39, David Kastrup escribió:

> Jeff King <peff@peff.net> writes:
>
>> I didn't ask for RFC quoting, but a nice side effect of URL syntax is
>> that they are machine parseable. If you wanted to write a tool to  
>> pick
>> the URLs out of this email and clone them as git repos, then how do  
>> you
>> find the end of:
>>
>>  http://host/git repo with spaces in the path
>>
>> compared to:
>>
>>  http://host/git+repo+with+spaces+in+the+path
>
> You just write <URL:http://host/git repo with spaces in the path> and
> have a good chance it will work.

As a data point, my email client correctly highlights only this one as  
a URL:

http://host/git+repo+with+spaces+in+the+path

Both of these are incorrectly highlighted:

http://host/git repo with spaces in the path
<URL:http://host/git repo with spaces in the path>

And this one too:

<http://host/git repo with spaces in the path>

So what does this mean in practice? I can right-click on the first one  
and choose "Copy". All the other ones I have to left-click and drag,  
being careful to limit the selection to the appropriate left and right  
boundaries.

Whether or not this is a big enough deal to actually care about is  
open to debate (obviously). Personally, I don't care too much seeing  
as I never use paths with spaces in them for this kind of thing.

Cheers,
Wincent

Re: remote#branch

[Robin Rosenberg]

onsdag 31 oktober 2007 skrev David Kastrup:
> Jeff King <peff@peff.net> writes:
> 
> > On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:
> >
> >> So if you want to follow the RFC, you'd better give a real reason. And no, 
> >> the existence of an RFC, and the fact that people use the same name for 
> >> things that superficially _look_ the same is not a reason in itself.
> >> 
> >> So hands up, people. Anybody who asked for RFC quoting. Give a damn 
> >> *reason* already!
> >
> > I didn't ask for RFC quoting, but a nice side effect of URL syntax is
> > that they are machine parseable. If you wanted to write a tool to pick
> > the URLs out of this email and clone them as git repos, then how do you
> > find the end of:
> >
> >   http://host/git repo with spaces in the path
> >
> > compared to:
> >
> >   http://host/git+repo+with+spaces+in+the+path
> 
> You just write <URL:http://host/git repo with spaces in the path> and
> have a good chance it will work.

It doesn't with KMail.

-- robin

Re: remote#branch

[Pascal Obry]

David Kastrup a écrit :
> You just write <URL:http://host/git repo with spaces in the path> and
> have a good chance it will work.

Well "good chance" is not an option for reliable software :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: remote#branch

[Petr Baudis]

On Tue, Oct 30, 2007 at 07:58:23PM -0400, Jeff King wrote:
>   http://host/git repo with spaces in the path
> 
> compared to:
> 
>   http://host/git+repo+with+spaces+in+the+path

Just pedantic side-note: these two URLs are not equivalent. '+' is valid
substitute for a space only in query string part of URL. In path you
have to use %20.

-- 
				Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish.		-- Marshall McLuhan

Re: remote#branch

[Pascal Obry]

Linus Torvalds a écrit :
> Nobody cares about git being consistent with a web browser. There is
> nothing in common.

I don't understand why you keep talking about web browser. URL is not a
web browser thing. It is the case that web browser are using URL, but
that's just one usage.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: remote#branch

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]

On Tue, Oct 30, 2007 at 07:59:45 -0700, Linus Torvalds wrote:
> > So, how should git deal with
> > 
> > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
> 
> The way it has always cared. Git itself does no quoting what-so-ever 
> (except for the *argument* quoting etc that it needs).
> 
> Now, the *transport* back-end may end up quoting it, of course, the same 
> way it may end up using some random protocol. The user shouldn't care 
> about the implementation details!
> 
> In the case of the git transport, there is no quoting even by the 
> transport protocol. In the case of http, libcurl would hopefully quote for 
> us.

So the three addresses will all be different, right?

> > compared to 
> > 
> > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
> 
> No difference, what-so-ever, that I can see. Git doesn't quote it.

Yes. But the server will unquote it. ' ' should not have been there, but it's
just passed through if it was. '+' is quoting for ' ' and '%20' is quoting
for ' ' as well. Therefore all these three addresses are the *SAME*.

Now the user expectation will be that when these are the same, the git://
ones above will be as well. But they are not. This is not about following any
RFC for sake of it, but about being consistent with ourselves.

> Notice how the fact that we use http:// doesn't actually mean that you can 
> feed the result to a web browser anyway? It's not like you get a "link" 
> that git follows. You get a name.
> 
> Yes, you can try to "co-locate" things so that something smart 
> disambiguates (maybe have an "index.html" file, so a web browser gets a 
> gitweb page, and git gets the raw data). But even then, notice how even 
> web browser will do the quoting for you: try
> 
> 	firefox "http://www.google.com/search?q=Html spaces"
> 
> just for fun.

Sure. There is no abiguity in decoding this, so why refuse it.

> [...]
>  - <remote shorthand> ("origin")
>  - <path> ("../git.git")
>  - <host>:<path> ("master.kernel.org:/pub/scm/...")
>  - <protocol>://<host>/<path> ("git://repo.or.cz/...")
> 
> See? We may not follow RFC's, but we follow "easy to use".

The first three don't look like URL ("URL" always means the thing defined by
RFC 2396, at least to me), so I don't expect any quoting there. But for the
last case http:// (and for that matter, sftp://) do use quoting, so I would
expect the quoting of something that differs only by starting with git:// to
work the same. 

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: remote#branch

[Linus Torvalds]

On Tue, 30 Oct 2007, Jan Hudec wrote:
> > 
> > Now, the *transport* back-end may end up quoting it, of course, the same 
> > way it may end up using some random protocol. The user shouldn't care 
> > about the implementation details!
> 
> Yes. But the server will unquote it. ' ' should not have been there, but it's
> just passed through if it was. '+' is quoting for ' ' and '%20' is quoting
> for ' ' as well. Therefore all these three addresses are the *SAME*.

Ok, you have some reading comprehension skills.

Read the above again.

I'd certainly hope that *curl* does the proper quoting. That's a transport 
issue.

		Linus

Re: remote#branch

[Erik Warendorph]

* Jan Hudec <bulb@ucw.cz> [2007-10-30 20:36:10 +0100]:
>
> On Tue, Oct 30, 2007 at 07:59:45 -0700, Linus Torvalds wrote:
> > > So, how should git deal with
> > >
> > > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
> >
> > The way it has always cared. Git itself does no quoting what-so-ever
> > (except for the *argument* quoting etc that it needs).
> >
> > Now, the *transport* back-end may end up quoting it, of course, the same
> > way it may end up using some random protocol. The user shouldn't care
> > about the implementation details!
> >
> > In the case of the git transport, there is no quoting even by the
> > transport protocol. In the case of http, libcurl would hopefully quote for
> > us.
>
> So the three addresses will all be different, right?
>
> > > compared to
> > >
> > > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
> >
> > No difference, what-so-ever, that I can see. Git doesn't quote it.
>
> Yes. But the server will unquote it. ' ' should not have been there, but it's
> just passed through if it was. '+' is quoting for ' ' and '%20' is quoting
> for ' ' as well. Therefore all these three addresses are the *SAME*.
>
> Now the user expectation will be that when these are the same, the git://
> ones above will be as well. But they are not. This is not about following any
> RFC for sake of it, but about being consistent with ourselves.

I don't think the

  '+' is quoting for ' '

part is fully correct, at least not if you're talking about
"real RFC 2396 URLs" (not "Git URLs").  I might misunderstand
you here, but there has also been other postings suggesting
that plus should/could be used instead of space, implying that
people think that pluses are always transformed to spaces in
URLs.  But if I understand RFC 2396 correctly, this is *not*
the case.

RFC 2396 says that pluses are treated as "reserved" in the
*query* part of the URL (ie on the right side of the question
mark) -- here they *are* transformed to spaces, although the
RFC itself doesn't really say specifically what happens to
them.  In the path part, pluses are not "reserved", they are
simply a "pchar" along with "unreserved", "escaped" and a
couple of other characters.  There is nothing in the RFC
implying that pluses in the path part will be transformed into
spaces, and in my experience this does not happen in practice
either.

To recap:

  (In the examples below <...> is used to mean legal URLs,
  while "..." is used to mean "the literal characters in the
  URL" (more or less))

  * In the query part:

      '%20' = '+' = a literal space
      '%2B' =       a literal plus

    For example:

        <http://example.com/somescript?v=x%20y>
      = <http://example.com/somescript?v=x+y>
      = "http://example.com/somescript?v=x y"

        <http://example.com/somescript?v=x%2By>
      = "http://example.com/somescript?v=x+y"

  * In the path part:

      '%20' =       a literal space
      '%2B' = '+' = a literal plus

    For example:

        <http://example.com/x%20y.html>
      = "http://example.com/x y.html"

        <http://example.com/x%2By>
      = <http://example.com/x+y>
      = "http://example.com/x+y"

I'm not advocating that "Git URLs" necessarily should be made
fully RFC 2396 compliant (neither am I nitpicking just for the
sake of nitpicking), I'm just pointing out that if someone
*should* want to make "Git URLs" fully or more RFC 2396
compliant in some way for some reason, having pluses being
automatically transformed to spaces in the path part of the URL
does not follow the RFC (as far as I understand it).

-- 
Erik Warendorph <erik@warendorph.org>

Re: remote#branch

[Johannes Schindelin]

Hi,

On Mon, 29 Oct 2007, Linus Torvalds wrote:

> On Tue, 30 Oct 2007, Theodore Tso wrote:
> 
> > Quick!  Which of the URL-like strings follow the URL quoting rules, 
> > and which ones don't?
> 
> Quick! WHO THE F*CK CARES?

I second this.

Should we -- ever -- encounter problems with the way we do things, we can 
still fix it.  So far, our "inconsistent" behaviour has not given me 
grief.

Ciao,
Dscho

Re: remote#branch

[Martin Langhoff]

On 10/30/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Quick! WHO THE F*CK CARES?

Ah, damn. In all the discussion & flamefesting to say that people
don't want to use the # character, noone talks about of what cogito
used it for.

Having something functionally similar to

  cg-clone git://foo.tld/bar.git#blue

would save a few steps -- and some potential confusion -- for projects
using GIT.

In case it's not clear what it does (not everyone here has used
cogito) it will create and checkout a branch tracking the "blue" head
on the repo when the clone is done. This is _instead of_ creating and
checking out the branch that tracks the configured "HEAD" of the repo.

IMHO is a quite nice thing to have -- and AFAICS we don't have it in
master or pu. I care about the shed for the bike, not its colour.
cheers,


m

Re: remote#branch

[Linus Torvalds]

On Wed, 31 Oct 2007, Martin Langhoff wrote:
> 
> Having something functionally similar to
> 
>   cg-clone git://foo.tld/bar.git#blue
> 
> would save a few steps -- and some potential confusion -- for projects
> using GIT.

I do agree with that "functionally similar", I just disagree with the 
syntax.

The thing is, we don't want a single branch name. Not for clone, not for 
fetch, not for pull, and not for push.

Yes, a single branch may be one common case, but it's definitely not the 
only one, and it's fundamentally the wrong thing to use as a definition of 
syntax. 

It's also the wrong thing to do for local stuff.

			Linus

Re: remote#branch

[Jeff King]

On Wed, Oct 31, 2007 at 01:41:12PM +1300, Martin Langhoff wrote:

> Having something functionally similar to
> 
>   cg-clone git://foo.tld/bar.git#blue
> 
> would save a few steps -- and some potential confusion -- for projects
> using GIT.
> 
> In case it's not clear what it does (not everyone here has used
> cogito) it will create and checkout a branch tracking the "blue" head
> on the repo when the clone is done. This is _instead of_ creating and
> checking out the branch that tracks the configured "HEAD" of the repo.

Actually, IIRC it won't fetch any of the non 'blue' refs.

Anyway, to recap (my impression of) the discussion leading up to this:
  - the cogito feature is useful
  - the cogito syntax does not allow for multiple branches to be
    specified
  - one such syntax proposed was git://foo.tld/bar.git#blue,red
  - one problem with that syntax is that comma is a valid character
    in the branch name, and '#' is a valid character in the repo name
  - one proposed solution was that '#' and ',' when used as data should
    be URL-encoded
  - flamefest begin

So I think nobody disagrees that such a feature is useful; there is
disagreement about the syntax.

-Peff

Re: remote#branch

[Martin Langhoff]

On 10/31/07, Jeff King <peff@peff.net> wrote:
> Actually, IIRC it won't fetch any of the non 'blue' refs.

You recall correctly, and that was a cogito misfeature. I don't think
git should follow that part of the spec ;-)

> Anyway, to recap (my impression of) the discussion leading up to this:
>   - the cogito feature is useful
...
>   - flamefest begin

Great summary. I read the first and last stages you describe (with a
trip in the middle distracting me). Heh.

No stress. Let the flames continue!


m

Re: remote#branch

[Jeff King]

On Wed, Oct 31, 2007 at 02:49:49PM +1300, Martin Langhoff wrote:

> > Actually, IIRC it won't fetch any of the non 'blue' refs.
> You recall correctly, and that was a cogito misfeature. I don't think
> git should follow that part of the spec ;-)

I'm not so sure. Junio keeps unrelated branches in git.git like 'html'
and 'todo'. Is it unreasonable to say "clone git.git, but only the todo
branch" and expect it _not_ to download the entire git history?

-Peff

Re: remote#branch

[Johannes Schindelin]

Hi,

On Tue, 30 Oct 2007, Jeff King wrote:

> Anyway, to recap (my impression of) the discussion leading up to this:
>   - the cogito feature is useful
>   - the cogito syntax does not allow for multiple branches to be
>     specified

Here somebody else than me (IIRC Junio) proposed this syntax:

	git clone --track <name> [--track <name2>] <url>

Nobody was interested enough to implement it.

I then proposed delimiting with spaces, since they were _not part of a 
URL_:

	git clone "<url> <name> <name2>"

but some people insisted on "#", which I pointed out (several times!) is a 
no go, and I actually provided reasons for that.

>   - one such syntax proposed was git://foo.tld/bar.git#blue,red
>   - one problem with that syntax is that comma is a valid character
>     in the branch name, and '#' is a valid character in the repo name
>   - one proposed solution was that '#' and ',' when used as data should
>     be URL-encoded
>   - flamefest begin
> 
> So I think nobody disagrees that such a feature is useful; there is
> disagreement about the syntax.

Probably there is not enough need, too, and the discussion will peter out 
again, without anybody letting some code talk, and I will not make the 
mistake again of reviving this discussion.  Promise.

Ciao,
Dscho

Re: remote#branch

[Linus Torvalds]

On Mon, 29 Oct 2007, Theodore Tso wrote:
> 
> So let's not call them URL's, since they're clearly not.

Hey, you go ahead.

Me, I'll refuse to make up a new name just because somebody thinks they 
"own" the concept of URL's.

Let's face it, nobody really cares.

		Linus

Re: remote#branch

[Johannes Schindelin]

Hi,

On Mon, 29 Oct 2007, Jan Hudec wrote:

> On Sun, Oct 28, 2007 at 00:01:57 +0100, Johannes Schindelin wrote:
> 
> > On Sat, 27 Oct 2007, Jan Hudec wrote:
> > 
> > > On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:
> > >
> > > > ',' is allowed in ref names, so ',' is out.
> > > 
> > > Actually since many characters that are allowed in ref name are not 
> > > allowed in URL at all, the ref-name has to be url-escaped. Which 
> > > brings all characters back in, because they can always be specified 
> > > escaped.
> > 
> > No.  The URL part of it has to be encoded.  But the ref names do 
> > _not_.  (If we really want to have a way to specify the remote URL and 
> > the branch(es) we want to fetch _at the same time_.)
> 
> If the branch names are not url-escaped, than the result is not an URL. 
> Which is just ugly and confusing. If it looks like an URL, it should 
> better be one.

So all you're saying is: it is not possible.

Well, discussion ended, I guess.

Ciao,
Dscho

Re: cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito

[Jonas Fonseca]

On 10/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 16 Oct 2007, Petr Baudis wrote:
> > I'm not sure this is good idea, Cogito is still quite frequently used
> > and it should be documented that it exists.
>
> I agree.  But maybe it could be marked as unmaintained?  Maybe someone
> steps up to maintain it.  Or, even better, comes up with a list of "this
> is what I like do regularly with cogito, but there's no easy way with core
> git" issues.

One thing that I occasionally miss is

  cg-export /path/to/directory/

And yes, I know it can be accomplished via "obscurities" like
git-archive+tar (or worse git-checkout-index) but I think having
an easy way to checkout to a directory could be great (and possibly
with the ability to apply substitutions with the recent discussion).

Else, I am really looking forward for the option parser work to provide
an easy way to list options. I found it very useful with Cogito.
Also, most of the "status" commands in Cogito seemd to provide a richer
default output geared towards human consumption. For example stuff like
git-branch -v and git remote -v flags would have been the default for
Cogito ... I think.

-- 
Jonas Fonseca

Re: cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito

[Petr Baudis]

On Wed, Oct 17, 2007 at 12:16:25AM +0200, Jonas Fonseca wrote:
> On 10/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Tue, 16 Oct 2007, Petr Baudis wrote:
> > > I'm not sure this is good idea, Cogito is still quite frequently used
> > > and it should be documented that it exists.
> >
> > I agree.  But maybe it could be marked as unmaintained?  Maybe someone
> > steps up to maintain it.  Or, even better, comes up with a list of "this
> > is what I like do regularly with cogito, but there's no easy way with core
> > git" issues.
> 
> One thing that I occasionally miss is
> 
>   cg-export /path/to/directory/
> 
> And yes, I know it can be accomplished via "obscurities" like
> git-archive+tar (or worse git-checkout-index) but I think having
> an easy way to checkout to a directory could be great (and possibly
> with the ability to apply substitutions with the recent discussion).
> 
> Else, I am really looking forward for the option parser work to provide
> an easy way to list options. I found it very useful with Cogito.
> Also, most of the "status" commands in Cogito seemd to provide a richer
> default output geared towards human consumption. For example stuff like
> git-branch -v and git remote -v flags would have been the default for
> Cogito ... I think.

A "me too" mail for once...

I fully second this. cg-export is one of the Cogito commands I still use
frequently. I wonder if there is any obvious piece of Git command set we
could glue this on (so that we don't introduce Yet Another Command)... I
think cg-export is better-named here than git-archive. ;-)

And some command in Git to easily get the equivalent of cg-status -g
output is something I probably miss the most in Git now. (Originally I
was about to say that I just miss an equivalent of cg-status, but
thinking about it, most of the time I'm interested only in either -g
(long branch info) or -w (git status output)).

-- 
				Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish.		-- Marshall McLuhan

Re: cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito

[Jonas Fonseca]

On Oct 31, 2007 6:09 PM, Petr Baudis <pasky@suse.cz> wrote:
> And some command in Git to easily get the equivalent of cg-status -g
> output is something I probably miss the most in Git now. (Originally I
> was about to say that I just miss an equivalent of cg-status, but
> thinking about it, most of the time I'm interested only in either -g
> (long branch info) or -w (git status output)).

Try `git branch -v` ... maybe with an added -a.

-- 
Jonas Fonseca