{"thread":{"id":"10294","subject":"[PATCH] Git homepage: remove all the references to Cogito","startedAt":"2007-10-15T21:38:00Z","lastAt":"2007-11-01T07:29:52Z","messageCount":75,"participants":["Paolo Ciarrocchi","Petr Baudis","Matthieu Moy","Luke Lu","Johannes Schindelin","Andreas Ericsson","Jan Hudec","Jonas Fonseca","Linus Torvalds","Theodore Tso","Junio C Hamano","Tom Prince","Pascal Obry","Randal L. Schwartz","Nicolas Pitre","Jeff King","Jakub Narebski","Martin Langhoff","David Kastrup","Wincent Colaiuta","Robin Rosenberg","Mike Hommey","Erik Warendorph"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"55916","messageId":"20071015233800.6306e414@paolo-desktop","threadId":"10294","inReplyTo":null,"subject":"[PATCH] Git homepage: remove all the references to Cogito","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2007-10-15T21:38:00Z","receivedAt":"2007-10-15T21:38:00Z","isPatch":true,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"It sounds like a good idea to remove all the references to Cogito from the git homepage since it's not longer supported.\nChanges tested with a local installation of the web server lighttpd\n\nSigned-off-by: Paolo Ciarrocchi \n---\n index.html | 12 +-----------\n 1 files changed, 1 insertions(+), 11 deletions(-)\n\ndiff --git a/index.html b/index.html\nindex 340aee0..41605ed 100644\n--- a/index.html\n+++ b/index.html\n@@ -94,7 +94,6 @@ Junio C Hamano.

\n \t-->\n \t
Maintaining external patches\n \t
Git for SVN users\n-\t
Cogito for CVS users\n \t
More to come soon...\n \t\n \n@@ -286,15 +285,6 @@ a gitweb interface, at http://repo.or.cz/.

\n \n
\n \n-
Cogito
\n-
\n-Cogito\n-is a popular version control system on top of Git.\n-It aims at seamless user interface and ease of use, providing\n-generally smoother user experience than the \"raw\" Git interface\n-and indeed also many other version control systems. However, it\n-also lacks many advanced capabilities of Git and is currently\n-being slowly phased out.
\n \n
StGIT
\n
Stacked Git provides\n@@ -340,7 +330,7 @@ with help of a group of hackers 'round the net.\n It is currently maintained by\n Junio C Hamano.

\n \n-

The user discussion and development of Git, Cogito and other tools related to Git\n+

The user discussion and development of Git and other tools related to Git\n takes place on the Git mailing list - everyone is welcome to post\n bug reports, feature requests, comments and patches to\n git@vger.kernel.org.\n-- \n1.5.3.4.206.g58ba4\n"},{"id":"55933","messageId":"20071016021933.GH12156@machine.or.cz","threadId":"10294","inReplyTo":"20071015233800.6306e414@paolo-desktop","subject":"Re: [PATCH] Git homepage: remove all the references to Cogito","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-10-16T02:19:33Z","receivedAt":"2007-10-16T02:19:33Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Oct 15, 2007 at 11:38:00PM +0200, Paolo Ciarrocchi wrote:\n> @@ -286,15 +285,6 @@ a gitweb interface, at http://repo.or.cz/.

\n> \n>
\n> \n> -
Cogito
\n> -
\n> -Cogito\n> -is a popular version control system on top of Git.\n> -It aims at seamless user interface and ease of use, providing\n> -generally smoother user experience than the \"raw\" Git interface\n> -and indeed also many other version control systems. However, it\n> -also lacks many advanced capabilities of Git and is currently\n> -being slowly phased out.
\n> \n>
StGIT
\n>
Stacked Git provides\n\nI'm not sure this is good idea, Cogito is still quite frequently used\nand it should be documented that it exists.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEarly to rise and early to bed makes a male healthy and wealthy and dead.\n -- James Thurber\n"},{"id":"55977","messageId":"vpqlka3sdka.fsf@bauges.imag.fr","threadId":"10294","inReplyTo":"20071016021933.GH12156@machine.or.cz","subject":"Re: [PATCH] Git homepage: remove all the references to Cogito","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-10-16T07:50:45Z","receivedAt":"2007-10-16T07:50:45Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Petr Baudis writes:\n\n> I'm not sure this is good idea, Cogito is still quite frequently used\n> and it should be documented that it exists.\n\nI think reformulating the mention to cogito (use past sentence like\n\"cogito was a popular ...\") would be better. As a side-effect, it\nwould also credit you for your work, which I think is fair :-).\n\n-- \nMatthieu\n"},{"id":"55979","messageId":"4d8e3fd30710160101p3579a719q9d4133cf3edf040f@mail.gmail.com","threadId":"10294","inReplyTo":"vpqlka3sdka.fsf@bauges.imag.fr","subject":"Re: [PATCH] Git homepage: remove all the references to Cogito","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2007-10-16T08:01:06Z","receivedAt":"2007-10-16T08:01:06Z","isPatch":true,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 10/16/07, Matthieu Moy wrote:\n> Petr Baudis writes:\n>\n> > I'm not sure this is good idea, Cogito is still quite frequently used\n> > and it should be documented that it exists.\n>\n> I think reformulating the mention to cogito (use past sentence like\n> \"cogito was a popular ...\") would be better. As a side-effect, it\n> would also credit you for your work, which I think is fair :-).\n\nYes, I probably be too rude. Sorry abot that Pasky, I just feel like\nthe home page is a bit confusing with regards to Cogito. My\nunderstanding is that it is no longer maintained and therefore we\nprobably should not encourage new user to use it.\n\nMaybe changing:\nCogito\n Cogito is a popular version control system on top of Git. It aims\nat seamless user interface and ease of use, providing generally\nsmoother user experience than the \"raw\" Git interface and indeed also\nmany other version control systems. However, it also lacks many\nadvanced capabilities of Git and is currently being slowly phased out.\n\ninto\nCogito\n Cogito was a popular version control system on top of Git. It aims\nat seamless user interface and ease of use, providing generally\nsmoother user experience than the \"raw\" Git interface and indeed also\nmany other version control systems. However, it also lacks many\nadvanced capabilities of Git and is not actively maintained any\nlonger.\n\nCiao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"55993","messageId":"3A2DCEC6-953A-41B0-AB9E-7374EEB625E8@vicaya.com","threadId":"10294","inReplyTo":"vpqlka3sdka.fsf@bauges.imag.fr","subject":"[PATCH] gitweb: Speed up get_projects_list for large source trees","fromName":"Luke Lu","fromEmail":"git@vicaya.com","sentAt":"2007-10-16T09:04:14Z","receivedAt":"2007-10-16T09:04:14Z","isPatch":true,"sender":{"key":"git@vicaya.com","avatar":null},"body":"Hi, I've been using git for a month now and loving it. This is my \nfirst ever patch for git using git. I spent sometime to find out why \nthe project listing is taking 200s, everytime! I guess that gitweb is \nmostly used to serve bare repositories, which would never encounter \nsuch problems. It takes .2s, after the patch on my laptop. That's \n1000x improvement for me (on Mac OS X 1.4.10.)\n\n__Luke\n\nSigned-off-by: Luke Lu \n---\ngitweb/gitweb.perl | 4 ++++\n1 files changed, 4 insertions(+), 0 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 3064298..a30eef9 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -1509,16 +1509,20 @@ sub git_get_projects_list {\n\t\t# remove the trailing \"/\"\n\t\t$dir =~ s!/+$!!;\n\t\tmy $pfxlen = length(\"$dir\");\n+\t\tmy $pfxdepth = ($dir =~ tr!/!!);\n\t\tFile::Find::find({\n\t\t\tfollow_fast => 1, # follow symbolic links\n\t\t\tfollow_skip => 2, # ignore duplicates\n+\t\t\tno_chdir => 1, # don't chdir into every directory\n\t\t\tdangling_symlinks => 0, # ignore dangling symlinks, silently\n\t\t\twanted => sub {\n\t\t\t\t# skip project-list toplevel, if we get it.\n\t\t\t\treturn if (m!^[/.]$!);\n\t\t\t\t# only directories can be git repositories\n\t\t\t\treturn unless (-d $_);\n+\t\t\t\t# don't traverse too deep (Find is super slow on os x)\n+\t\t\t\treturn if tr!/!! - $pfxdepth > 2 && ($File::Find::prune = 1);\n\t\t\t\tmy $subdir = substr($File::Find::name, $pfxlen + 1);\n\t\t\t\t# we check related file in $projectroot\n--\n1.5.3.4\n"},{"id":"56010","messageId":"Pine.LNX.4.64.0710161139530.25221@racer.site","threadId":"10294","inReplyTo":"20071016021933.GH12156@machine.or.cz","subject":"cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T10:49:58Z","receivedAt":"2007-10-16T10:49:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Oct 2007, Petr Baudis wrote:\n\n> On Mon, Oct 15, 2007 at 11:38:00PM +0200, Paolo Ciarrocchi wrote:\n> > @@ -286,15 +285,6 @@ a gitweb interface, at http://repo.or.cz/.

\n> > \n> >
\n> > \n> > -
Cogito
\n> > -
\n> > -Cogito\n> > -is a popular version control system on top of Git.\n> > -It aims at seamless user interface and ease of use, providing\n> > -generally smoother user experience than the \"raw\" Git interface\n> > -and indeed also many other version control systems. However, it\n> > -also lacks many advanced capabilities of Git and is currently\n> > -being slowly phased out.
\n> > \n> >
StGIT
\n> >
Stacked Git provides\n> \n> I'm not sure this is good idea, Cogito is still quite frequently used\n> and it should be documented that it exists.\n\nI agree. But maybe it could be marked as unmaintained? Maybe someone \nsteps up to maintain it. Or, even better, comes up with a list of \"this \nis what I like do regularly with cogito, but there's no easy way with core \ngit\" issues.\n\nIn related news, I recently thought about the url#branch issue.\n\nThere were three arguments against it AFAIR: \"#\" is a comment marker, and \nthis syntax is not extensible to more than one branch names. And that the \nbranch name is not really a part of the URL.\n\nTurns out that I am not so sure about the last two issues.\n\nIt is easily extensible to more than one branch by remote#branch1#branch2, \nand in a very real sense, this is a resource locator.\n\nAnd we could replace the \"#\" by every character that is illegal in ref \nnames as well as URLs. I propose SPC. ('#' is allowed in refnames.)\n\nCiao,\nDscho\n"},{"id":"56080","messageId":"4714ECE5.9020502@op5.se","threadId":"10294","inReplyTo":"3A2DCEC6-953A-41B0-AB9E-7374EEB625E8@vicaya.com","subject":"Re: [PATCH] gitweb: Speed up get_projects_list for large source trees","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-16T16:55:01Z","receivedAt":"2007-10-16T16:55:01Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Luke Lu wrote:\n> Hi, I've been using git for a month now and loving it.\n\nHello Luke, and welcome to the community :)\n\n> This is my first ever patch for git using git.\n\nIt shows. The patch is whitespace damaged, and the commit message leaves\na little something to desire. I suggest you read through\nDocumentation/SubmittingPatches and then re-send your patch. Try sending\nto yourself and looking at the result with a monospace font. It's what I\nalways do to make sure patches look okay before sending them to the list.\n\nNot trying to be rude or anything. Oldtime list-members sometimes get to\nhear the exact same thing.\n\nAlso, Junio, the maintainer, is currently away, so don't worry if your\npatches are left in limbo for some time. Someone will pick it up and\ncarry it forward for Junio to pull, or he'll hack up some script to\nget all patces from his mailbox and review them one by one. He's a very\nthorough fellow, usually.\n\n> I spent sometime to find out why the \n> project listing is taking 200s, everytime! I guess that gitweb is mostly \n> used to serve bare repositories, which would never encounter such \n> problems. It takes .2s, after the patch on my laptop. That's 1000x \n> improvement for me (on Mac OS X 1.4.10.)\n> \n\nSweet job :)\n\nI'll have to test this, as we've got a few repos at work with a checked out\nworking tree connected to the repos. I haven't run into your issues though,\nbut perhaps that's because we run it under Linux.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56124","messageId":"20071016210904.GI26127@efreet.light.src","threadId":"10294","inReplyTo":"Pine.LNX.4.64.0710161139530.25221@racer.site","subject":"Re: remote#branch","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-10-16T21:09:04Z","receivedAt":"2007-10-16T21:09:04Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Oct 16, 2007 at 11:49:58 +0100, Johannes Schindelin wrote:\n> In related news, I recently thought about the url#branch issue.\n> \n> There were three arguments against it AFAIR: \"#\" is a comment marker, and \n> this syntax is not extensible to more than one branch names. And that the \n> branch name is not really a part of the URL.\n> \n> Turns out that I am not so sure about the last two issues.\n> \n> It is easily extensible to more than one branch by remote#branch1#branch2, \n> and in a very real sense, this is a resource locator.\n> \n> And we could replace the \"#\" by every character that is illegal in ref \n> names as well as URLs. I propose SPC. ('#' is allowed in refnames.)\n\nIt's a question, whether the branch name is part of the URI, or a fragment.\n\nCurrent usage suggests it is a fragment, but according to the URL\nspecification that is supposed to mean that the resource is always accessed\nthe same (fragment is NOT part of the URL) and the fragment only affects\nlocal handling. Which I don't think is really true.\n\nIf it is a fragment, than \"#\" is the only correct separator and should stay\nthat way.\n\nIf it is not a true fragment, than we might want to phase it out in favor of\nsomething else. But I would strongly prefer staying within characters allowed\nin URI (as per rfc2396). We could consider whether the branch is not\na component parameter -- which would imply \";\" as separator, but I would vote\nagainst that on the basis that it's shell special. Non-special characters\nallowed by URL in this context would be \":\", \"@\", \"=\", \"+\", and \",\", of which\n\":\" or \"@\" seem best to me.\n\nAs for multiple branches, separating them with \",\" feels logical to me, no\nmatter what separates them from the repository path. On the other hand given\nthat neither \":\" nor \"@\" is allowed in refnames, reusing the same separator\nwould make sense especially if git switched to either of those.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"56129","messageId":"Pine.LNX.4.64.0710162228560.25221@racer.site","threadId":"10294","inReplyTo":"20071016210904.GI26127@efreet.light.src","subject":"Re: remote#branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T21:35:25Z","receivedAt":"2007-10-16T21:35:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Oct 2007, Jan Hudec wrote:\n\n> If it is a fragment, than \"#\" is the only correct separator and should \n> stay that way.\n\nYou did not listen, did you? '#' is allowed in ref names. Therefore this \ncharacter really would lock us in to only ever reference _one_ and _only_ \none remote branch at a time. This might have worked for cogito, but it \ndoes not for git.\n\nSo, I say it again, '#' is _out_.\n\n> If it is not a true fragment, than we might want to phase it out in \n> favor of something else. But I would strongly prefer staying within \n> characters allowed in URI (as per rfc2396).\n\nIf you do that, \"http://\" would be ambiguous, wouldn't \nit? This would already reference an HTTP resource, and you could not \nembed refnames into the URL.\n\n> As for multiple branches, separating them with \",\" feels logical to me, \n> no matter what separates them from the repository path. On the other \n> hand given that neither \":\" nor \"@\" is allowed in refnames, reusing the \n> same separator would make sense especially if git switched to either of \n> those.\n\n',' is allowed in ref names, so ',' is out.\n\nCiao,\nDscho\n"},{"id":"56134","messageId":"2c6b72b30710161516j5c029847r1acb3ce2d88344a1@mail.gmail.com","threadId":"10294","inReplyTo":"Pine.LNX.4.64.0710161139530.25221@racer.site","subject":"Re: cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2007-10-16T22:16:25Z","receivedAt":"2007-10-16T22:16:25Z","isPatch":true,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On 10/16/07, Johannes Schindelin wrote:\n> On Tue, 16 Oct 2007, Petr Baudis wrote:\n> > I'm not sure this is good idea, Cogito is still quite frequently used\n> > and it should be documented that it exists.\n>\n> I agree. But maybe it could be marked as unmaintained? Maybe someone\n> steps up to maintain it. Or, even better, comes up with a list of \"this\n> is what I like do regularly with cogito, but there's no easy way with core\n> git\" issues.\n\nOne thing that I occasionally miss is\n\n cg-export /path/to/directory/\n\nAnd yes, I know it can be accomplished via \"obscurities\" like\ngit-archive+tar (or worse git-checkout-index) but I think having\nan easy way to checkout to a directory could be great (and possibly\nwith the ability to apply substitutions with the recent discussion).\n\nElse, I am really looking forward for the option parser work to provide\nan easy way to list options. I found it very useful with Cogito.\nAlso, most of the \"status\" commands in Cogito seemd to provide a richer\ndefault output geared towards human consumption. For example stuff like\ngit-branch -v and git remote -v flags would have been the default for\nCogito ... I think.\n\n-- \nJonas Fonseca\n"},{"id":"56145","messageId":"20071016232058.GA18279@machine.or.cz","threadId":"10294","inReplyTo":"3A2DCEC6-953A-41B0-AB9E-7374EEB625E8@vicaya.com","subject":"Re: [PATCH] gitweb: Speed up get_projects_list for large source trees","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-10-16T23:20:58Z","receivedAt":"2007-10-16T23:20:58Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Tue, Oct 16, 2007 at 02:04:14AM -0700, Luke Lu wrote:\n> Hi, I've been using git for a month now and loving it. This is my first \n> ever patch for git using git. I spent sometime to find out why the project \n> listing is taking 200s, everytime! I guess that gitweb is mostly used to \n> serve bare repositories, which would never encounter such problems. It \n> takes .2s, after the patch on my laptop. That's 1000x improvement for me \n> (on Mac OS X 1.4.10.)\n\n that'd be sweet to have but this is unfortunately not so simple; this\nchange would e.g. break gitweb on repo.or.cz, where some projects can\nlive quite deep inside the tree due to forks.\n\n I guess the best way would be to introduce a configuration option that\nlets you potentially limit the $pfxdepth, but does not force the limit.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEarly to rise and early to bed makes a male healthy and wealthy and dead.\n -- James Thurber\n"},{"id":"57374","messageId":"20071027204757.GA3058@efreet.light.src","threadId":"10294","inReplyTo":"Pine.LNX.4.64.0710162228560.25221@racer.site","subject":"Re: remote#branch","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-10-27T20:47:57Z","receivedAt":"2007-10-27T20:47:57Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 16 Oct 2007, Jan Hudec wrote:\n> \n> > If it is a fragment, than \"#\" is the only correct separator and should \n> > stay that way.\n> \n> You did not listen, did you? '#' is allowed in ref names. Therefore this \n> character really would lock us in to only ever reference _one_ and _only_ \n> one remote branch at a time. This might have worked for cogito, but it \n> does not for git.\n> \n> So, I say it again, '#' is _out_.\n\nThat does not imply it can't separate the ref from the repository...\n\n> > If it is not a true fragment, than we might want to phase it out in \n> > favor of something else. But I would strongly prefer staying within \n> > characters allowed in URI (as per rfc2396).\n> \n> If you do that, \"http://\" would be ambiguous, wouldn't \n> it? This would already reference an HTTP resource, and you could not \n> embed refnames into the URL.\n\n... and because of this actually has to. You are right.\n\n> > As for multiple branches, separating them with \",\" feels logical to me, \n> > no matter what separates them from the repository path. On the other \n> > hand given that neither \":\" nor \"@\" is allowed in refnames, reusing the \n> > same separator would make sense especially if git switched to either of \n> > those.\n> \n> ',' is allowed in ref names, so ',' is out.\n\nActually since many characters that are allowed in ref name are not allowed\nin URL at all, the ref-name has to be url-escaped. Which brings all\ncharacters back in, because they can always be specified escaped.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"57380","messageId":"Pine.LNX.4.64.0710280000240.4362@racer.site","threadId":"10294","inReplyTo":"20071027204757.GA3058@efreet.light.src","subject":"Re: remote#branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-27T23:01:57Z","receivedAt":"2007-10-27T23:01:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 27 Oct 2007, Jan Hudec wrote:\n\n> On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:\n>\n> > ',' is allowed in ref names, so ',' is out.\n> \n> Actually since many characters that are allowed in ref name are not \n> allowed in URL at all, the ref-name has to be url-escaped. Which brings \n> all characters back in, because they can always be specified escaped.\n\nNo. The URL part of it has to be encoded. But the ref names do _not_. \n(If we really want to have a way to specify the remote URL and the \nbranch(es) we want to fetch _at the same time_.)\n\nCiao,\nDscho\n"},{"id":"57487","messageId":"20071029174000.GA4449@efreet.light.src","threadId":"10294","inReplyTo":"Pine.LNX.4.64.0710280000240.4362@racer.site","subject":"Re: remote#branch","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-10-29T17:40:00Z","receivedAt":"2007-10-29T17:40:00Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Oct 28, 2007 at 00:01:57 +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sat, 27 Oct 2007, Jan Hudec wrote:\n> \n> > On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:\n> >\n> > > ',' is allowed in ref names, so ',' is out.\n> > \n> > Actually since many characters that are allowed in ref name are not \n> > allowed in URL at all, the ref-name has to be url-escaped. Which brings \n> > all characters back in, because they can always be specified escaped.\n> \n> No. The URL part of it has to be encoded. But the ref names do _not_. \n> (If we really want to have a way to specify the remote URL and the \n> branch(es) we want to fetch _at the same time_.)\n\nIf the branch names are not url-escaped, than the result is not an URL. Which\nis just ugly and confusing. If it looks like an URL, it should better be one.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"57488","messageId":"alpine.LFD.0.999.0710291112590.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"20071029174000.GA4449@efreet.light.src","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-29T18:17:12Z","receivedAt":"2007-10-29T18:17:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 29 Oct 2007, Jan Hudec wrote:\n> \n> If the branch names are not url-escaped, than the result is not an URL. Which\n> is just ugly and confusing. If it looks like an URL, it should better be one.\n\nGit remote names already aren't \"url\"s in the http sense. \n\nWe say \"master:some.host/file/goes here/without/any/stupid/web-escapes\" \nfor the ssh names, and the same goes for \"file:///name here\" etc.\n\nPeople who think that git URL's are web-pages had better wake up and smell \nthe coffee. They aren't. They never were. They never *should* be.\n\nThis whole argument is idiotic. The #branch format was a mistake of \ncogito. Cogito is dead. Get over it already.\n\nWe have a format already, and it has nothing to do with '#' or any idiotic \nweb escape, or anything else.\n\n\t\t\tLinus\n"},{"id":"57489","messageId":"Pine.LNX.4.64.0710291832290.4362@racer.site","threadId":"10294","inReplyTo":"20071029174000.GA4449@efreet.light.src","subject":"Re: remote#branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-29T18:32:56Z","receivedAt":"2007-10-29T18:32:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 29 Oct 2007, Jan Hudec wrote:\n\n> On Sun, Oct 28, 2007 at 00:01:57 +0100, Johannes Schindelin wrote:\n> \n> > On Sat, 27 Oct 2007, Jan Hudec wrote:\n> > \n> > > On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:\n> > >\n> > > > ',' is allowed in ref names, so ',' is out.\n> > > \n> > > Actually since many characters that are allowed in ref name are not \n> > > allowed in URL at all, the ref-name has to be url-escaped. Which \n> > > brings all characters back in, because they can always be specified \n> > > escaped.\n> > \n> > No. The URL part of it has to be encoded. But the ref names do \n> > _not_. (If we really want to have a way to specify the remote URL and \n> > the branch(es) we want to fetch _at the same time_.)\n> \n> If the branch names are not url-escaped, than the result is not an URL. \n> Which is just ugly and confusing. If it looks like an URL, it should \n> better be one.\n\nSo all you're saying is: it is not possible.\n\nWell, discussion ended, I guess.\n\nCiao,\nDscho\n"},{"id":"57491","messageId":"20071029214925.GH21133@thunk.org","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710291112590.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-29T21:49:25Z","receivedAt":"2007-10-29T21:49:25Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Oct 29, 2007 at 11:17:12AM -0700, Linus Torvalds wrote:\n> Git remote names already aren't \"url\"s in the http sense. \n> \n> We say \"master:some.host/file/goes here/without/any/stupid/web-escapes\" \n> for the ssh names, and the same goes for \"file:///name here\" etc.\n> \n> People who think that git URL's are web-pages had better wake up and smell \n> the coffee. They aren't. They never were. They never *should* be.\n\nWell, the confusion is that we refer to things that look like\n\"git://git.kernel.org/pub/scm/git/git.git\" as if it were a URL. In\nfact, you did so yourself in the last paragraph above. \"People who\nthink that git URL's\".... but in fact, whether or not Universal\nResource Locators (URL's) in the RFC 3986 sense requires quoting\ndoesn't matter whether or not they are web pages or not. If they are\nformal URL's in the sense of RFC 3986, it doesn't matter whether they\nare http URL's, or ldap URL's, or telephone URL's, etc. they are\nsupposed to be quoted whether or not they appear in a web form or not.\nThe whole point of URL's is that they are *uniform*.\n\nSo what that means is the much more correct statement is:\n\n\"People who think the names that people specify that to git, which\nsometimes include names that look very much like URL's, especially\nwhen they begin 'git://' or 'http://', and they think they are really\nRFC 3986 URL's had better wake up and smell the coffee. They aren't.\nThey never were. The they never *should* be. \n\nThe best that we can say given existing usage is that what git accepts\nis a superset of what is allowable by RFC 3986 syntactically, and that\ngit in general doesn't do any URL-style quoting, even when given a\nname that looks syntactically like a http-style URL that begins\n'http://'.\"\n\nWhat this means in practice though is that people would be well\nadvised not to pick locator names (NOT URL's) that contain characters\nthat normally would require escaping by RFC 3986 rules, since the\ninconsistency of whether tools that expect URL-style quoting rules\nwill probably cause user and tools confusion. Hence, it would\nprobably be a bad idea to place a directory pathname that included the\n'#' character on a web server and expect that resulting git:// and\nhttp:// names generated by an Apache web server and gitweb scripts to\ndo sane things, not to mention direct access via git:// names used\nwhen you do a \"git push\" to said respository. Sometimes the name will\nrequire RFC 3968 quoting, and sometimes it may not be quoted using RFC\n3968 rules, depending on which tool you are using.\n\nI do agree that the Cogito '#' notation makes things worse, not\nbetter, because it encourages a bigger separation between the RFC 3986\nrules, and what the git tool accepts in practice --- which are not\nURL's, no matter how much some of our git-style names superficially\nlook like URL's. \n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"57493","messageId":"alpine.LFD.0.999.0710291545250.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"20071029214925.GH21133@thunk.org","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-29T22:57:41Z","receivedAt":"2007-10-29T22:57:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 29 Oct 2007, Theodore Tso wrote:\n> \n> Well, the confusion is that we refer to things that look like\n> \"git://git.kernel.org/pub/scm/git/git.git\" as if it were a URL.\n\nSure, but \"URL\" in human-speak has nothing to do with an RFC.\n\nI dislike language-lawyerese. Why the hell do people think that human \nlanguage should follow the RFC's?\n\nGit addresses look like URL's, and they act like URL's, but dammit, git \nisn't a web browser, and it's not interested in acting like one. \n\nAnd \"standards\" are only as good as they are useful. XML is a piece of \ncrap despite being a standard because it makes no sense. Similarly, \"URL \nquoting\" is a piece of crap when _it_ makes no sense. Having a RFC or an \nISO standard doesn't change anything, and doesn't imply that human \ncommunication (or indeed, even machine communication) should care.\n\n\t\t\tLinus\n"},{"id":"57497","messageId":"Pine.LNX.4.64.0710292348540.4362@racer.site","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710291545250.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-29T23:49:28Z","receivedAt":"2007-10-29T23:49:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 29 Oct 2007, Linus Torvalds wrote:\n\n> And \"standards\" are only as good as they are useful. XML is a piece of \n> crap despite being a standard because it makes no sense.\n\nTo be fair, there are uses for XML. On Halloween, for example.\n\nSorry, could not resist,\nDscho\n"},{"id":"57516","messageId":"20071030030104.GK21133@thunk.org","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710291545250.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-30T03:01:04Z","receivedAt":"2007-10-30T03:01:04Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Oct 29, 2007 at 03:57:41PM -0700, Linus Torvalds wrote:\n> Sure, but \"URL\" in human-speak has nothing to do with an RFC.\n> \n> I dislike language-lawyerese. Why the hell do people think that human \n> language should follow the RFC's?\n> \n> Git addresses look like URL's, and they act like URL's, but dammit, git \n> isn't a web browser, and it's not interested in acting like one. \n\nThe quoting rules aren't specific to a web browser; the whole point of\nURL's is that they are uniform so that programs know how to handle\nthem without needing information specific to the URL type. Hence the\nquoting rules apply to all applications using URL's, whether it's CUPS\nusing a url such as: ipp://example.com/printer/tiger/bob or LDAP using\na url such as: ldap://ldap.example.com/dc=example,dc=com?postalAddress.\n\nIt's just git which is different here. Having a uniform set of\nprocessing rules are *useful* for applications and libraries that are\nparsing URL's, not just for language-lawyer wanking. Not that git\naddresses that are layered on top of http is all that well supported\nany more, but in that case we really are using an http-style URL ---\nbut yet git doesn't do URL quoting, because, well, it doesn't. Yet in\nthat case it's very clear the http address is really a URL, and it's\narguably a defect that git doesn't handle an http address the way all\nother applications handle http URL's.\n\nAt the very least, if we aren't going to change git, we should hang a\nbig fat sign in the documentation saying that although git location\nnames that begin git:// look like URL's, and smell like URL's, they\naren't treated the same way that all other applications treat URL's,\nand the user shouldn't be surprised by this. Furthermore, choosing\npathnames so that git:// and gitweb http:// addresses don't require\nURL-style quoting, will probably save the user a fair amount of pain\nand confusion because git refuses to treat git addresses as URL's.\n\nIt would probably also be a good idea to expurgate URL's from the\ndocumentations, because, well, they aren't URL's. Git doesn't treat\nthem like URL's, and you've said you aren't interested in changing git\nto treat them like URL's, and finally git:// isn't a registered URL\nscheme name with the IANA registration authority. So let's not call\nthem URL's, since they're clearly not.\n\n \t \t \t \t - Ted\n"},{"id":"57517","messageId":"7vtzo9s221.fsf@gitster.siamese.dyndns.org","threadId":"10294","inReplyTo":"20071030030104.GK21133@thunk.org","subject":"Re: remote#branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-30T03:40:06Z","receivedAt":"2007-10-30T03:40:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> It would probably also be a good idea to expurgate URL's from the\n> documentations, because, well, they aren't URL's. Git doesn't treat\n> them like URL's, and you've said you aren't interested in changing git\n> to treat them like URL's, and finally git:// isn't a registered URL\n> scheme name with the IANA registration authority. So let's not call\n> them URL's, since they're clearly not.\n\nAre you playing reverse psychology, encouraging us to switch to\nRFC-conforming quoting?\n"},{"id":"57524","messageId":"20071030044026.GA9600@thunk.org","threadId":"10294","inReplyTo":"7vtzo9s221.fsf@gitster.siamese.dyndns.org","subject":"Re: remote#branch","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-30T04:40:26Z","receivedAt":"2007-10-30T04:40:26Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Oct 29, 2007 at 08:40:06PM -0700, Junio C Hamano wrote:\n> Theodore Tso writes:\n> \n> > It would probably also be a good idea to expurgate URL's from the\n> > documentations, because, well, they aren't URL's. Git doesn't treat\n> > them like URL's, and you've said you aren't interested in changing git\n> > to treat them like URL's, and finally git:// isn't a registered URL\n> > scheme name with the IANA registration authority. So let's not call\n> > them URL's, since they're clearly not.\n> \n> Are you playing reverse psychology, encouraging us to switch to\n> RFC-conforming quoting?\n\nWell, URL's have a specific meaning and they're not for web browsing.\nThey are used to specify the addresses of printers, e-mail addresses,\nLDAP servers, and much more. Git is using something that looks like\nURL's, but they they don't follow the URL rules. So this brings up\ninteresting questions when a git webpage displayes something like\nthis (taken from repo.or.cz):\n\nMirror URL git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n http://repo.or.cz/r/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\nPush URL git+ssh://repo.or.cz/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n\nQuick! Which of the URL-like strings follow the URL quoting rules,\nand which ones don't? And if you have a character that must be quoted\nin the pthname, should be quoted in in the http:// line? And does it\nmatter if you are passing that URL-like string to a web browser or to\ngit-clone?\n\nThis is not language lawyering; this is a consistency issue that\nmatters. But if Linus is going to say that git isn't going to follow\nthe URL quoting rules because it isn't a web browser, then clearly\nwhat we are using aren't URL's. So let's not *call* them URL's in our\ndocumentation, because we're not following the URL rules. That way is\nonly going to spawn more confusion.\n\nIs this reverse psychology? Well, I think git needs to pick whether\nwe operate on URL's or just things that *look* like URL's. Either\nway, the documentation should be specific about what's going on. Me,\nI'd prefer that git be liberal in what it accepts, and conservative in\nwhat it sends. That means that it would be useful if git could accept\nURL's that are correctly quoted, and let things slide if characters\nthat should be quoted, aren't. Git rarely actually emits URL's, and\nmercifully people rarely use things like '#' characters in their\npathnames, so I don't think it would be that hard to make the\ntransition.\n\n \t \t \t \t \t - Ted\n"},{"id":"57526","messageId":"alpine.LFD.0.999.0710292147080.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"20071030030104.GK21133@thunk.org","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-30T04:50:02Z","receivedAt":"2007-10-30T04:50:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 29 Oct 2007, Theodore Tso wrote:\n> \n> So let's not call them URL's, since they're clearly not.\n\nHey, you go ahead.\n\nMe, I'll refuse to make up a new name just because somebody thinks they \n\"own\" the concept of URL's.\n\nLet's face it, nobody really cares.\n\n\t\tLinus\n"},{"id":"57527","messageId":"alpine.LFD.0.999.0710292150400.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"20071030044026.GA9600@thunk.org","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-30T04:51:47Z","receivedAt":"2007-10-30T04:51:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 30 Oct 2007, Theodore Tso wrote:\n> \n> Mirror URL git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n> http://repo.or.cz/r/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n> Push URL git+ssh://repo.or.cz/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n\nNo.\n\nThe push url is generally written as\n\n\trepo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n\nTough.\n\n> Quick! Which of the URL-like strings follow the URL quoting rules,\n> and which ones don't?\n\nQuick! WHO THE F*CK CARES?\n\n\t\tLinus\n"},{"id":"57529","messageId":"20071030053732.GA16963@hermes.priv","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710292150400.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Tom Prince","fromEmail":"tom.prince@ualberta.net","sentAt":"2007-10-30T05:37:32Z","receivedAt":"2007-10-30T05:37:32Z","isPatch":false,"sender":{"key":"tom.prince@ualberta.net","avatar":"https://gravatar.com/avatar/a0ad19caee7618876339485106ec994f5202505eecd210ba5c0bd869feaa555a?d=mp&s=160"},"body":"On Mon, Oct 29, 2007 at 09:51:47PM -0700, Linus Torvalds wrote:\n> \n> \n> On Tue, 30 Oct 2007, Theodore Tso wrote:\n> > \n> > Mirror URL git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n> > http://repo.or.cz/r/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n> > Push URL git+ssh://repo.or.cz/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n> \n> No.\n> \n> The push url is generally written as\n> \n> \trepo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n> \n> Tough.\n\nBut gitweb (on git.kernel.org and repo.or.cz) both give git:// locators.\n\n> \n> > Quick! Which of the URL-like strings follow the URL quoting rules,\n> > and which ones don't?\n> \n> Quick! WHO THE F*CK CARES?\n> \n\nSo, how should git deal with\n\ngit://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git\ngit://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git\ngit://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git\n\ncompared to \n\nhttp://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git\nhttp://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git\nhttp://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git\n\nNote: this doesn't have anything to do with server:/path/to/repo\n\nNot that I care, but git should probably handle things consistently.\n\n Tom\n"},{"id":"57555","messageId":"Pine.LNX.4.64.0710301001100.4362@racer.site","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710292150400.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-30T10:02:07Z","receivedAt":"2007-10-30T10:02:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 29 Oct 2007, Linus Torvalds wrote:\n\n> On Tue, 30 Oct 2007, Theodore Tso wrote:\n> \n> > Quick! Which of the URL-like strings follow the URL quoting rules, \n> > and which ones don't?\n> \n> Quick! WHO THE F*CK CARES?\n\nI second this.\n\nShould we -- ever -- encounter problems with the way we do things, we can \nstill fix it. So far, our \"inconsistent\" behaviour has not given me \ngrief.\n\nCiao,\nDscho\n"},{"id":"57584","messageId":"alpine.LFD.0.999.0710300738550.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"20071030053732.GA16963@hermes.priv","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-30T14:59:45Z","receivedAt":"2007-10-30T14:59:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 30 Oct 2007, Tom Prince wrote:\n> > The push url is generally written as\n> > \n> > \trepo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git\n> > \n> > Tough.\n> \n> But gitweb (on git.kernel.org and repo.or.cz) both give git:// locators.\n\nYes, for anonymous pulling.\n\nThe thing is, git takes something much more extended than a \"RFC url\".\n\nWe use pathnames. Not a \"quoted mess\". Regular, bog-standard, normal unix \npathnames.\n\nOn Windows, I assume (and hope) that git uses the native-style Windows \npathnames, and you can do \"git pull d:\\system\\ugh\" if you want to.\n\nAnd I think we should care a whole lot about interacting with the *user* \nand actual programs that git shares code with, than interacting with some \nidiotic RFC that has absolutely zero to do with us, regardless of whether \nwe use the name \"url\" or not.\n\nFor example, the reason we use \"host:/path\" for pushing over ssh (and \npulling, for that matter), is that that's the same syntax that scp uses. \nIt's a natural fit. And I hope to God nobody seriously argues that we \nshouldn't use regular pathnames on the local disk? \n\n> > Quick! WHO THE F*CK CARES?\n\n[ Btw, sorry for the french. I blame being tired and ina bad mood, but I \n also blame the fact that I absolutely *detest* arguments based on \n standards. If you cannot back it up with a real usage scenario, you \n shouldn't even mention the standard ]\n\n> So, how should git deal with\n> \n> git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git\n> git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git\n> git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git\n\nThe way it has always cared. Git itself does no quoting what-so-ever \n(except for the *argument* quoting etc that it needs).\n\nNow, the *transport* back-end may end up quoting it, of course, the same \nway it may end up using some random protocol. The user shouldn't care \nabout the implementation details!\n\nIn the case of the git transport, there is no quoting even by the \ntransport protocol. In the case of http, libcurl would hopefully quote for \nus.\n\n> compared to \n> \n> http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git\n> http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git\n> http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git\n\nNo difference, what-so-ever, that I can see. Git doesn't quote it.\n\nNotice how the fact that we use http:// doesn't actually mean that you can \nfeed the result to a web browser anyway? It's not like you get a \"link\" \nthat git follows. You get a name.\n\nYes, you can try to \"co-locate\" things so that something smart \ndisambiguates (maybe have an \"index.html\" file, so a web browser gets a \ngitweb page, and git gets the raw data). But even then, notice how even \nweb browser will do the quoting for you: try\n\n\tfirefox \"http://www.google.com/search?q=Html spaces\"\n\njust for fun.\n\nNotice? The thing is, \"strict RFC following\" makes no sense:\n\n - the git syntax is (and HAS TO BE to be user friendly) a real extension \n on any \"strict RFC URL\" anyway, since it is a lot more important to \n interact well with normal unix tools (ie use regular filenames, and use \n the same syntax as \"cp\", \"mv\" and \"find\" etc uses!)\n\n Ergo: we cannot and MUST NOT care about the \"URL RFC\" too deeply \n anyway.\n\n - \n\n> Not that I care, but git should probably handle things consistently.\n\nGit has been, and *is* entirely consistent. It uses convenient repo names. \nIf you don't want to call them url's, then call them \"repository name\". \nCall them whatever. But they are 100% obvious, even if there are multiple \nforms of them (and *none* of the forms do any quoting at all):\n\n - (\"origin\")\n - (\"../git.git\")\n - : (\"master.kernel.org:/pub/scm/...\")\n - :/// (\"git://repo.or.cz/...\")\n\nSee? We may not follow RFC's, but we follow \"easy to use\".\n\nAnd btw, that's really much much MUCH more important. It's why the git \nconfig file is in a \"ini\"-like format. It's readable. It's not the insane \nRFC crap that would result if somebody had decided that standards are more \nimportant than being sane.\n\n\t\t\tLinus\n"},{"id":"57587","messageId":"20071030160232.GB2640@hermes.priv","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710300738550.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Tom Prince","fromEmail":"tom.prince@ualberta.net","sentAt":"2007-10-30T16:02:33Z","receivedAt":"2007-10-30T16:02:33Z","isPatch":false,"sender":{"key":"tom.prince@ualberta.net","avatar":"https://gravatar.com/avatar/a0ad19caee7618876339485106ec994f5202505eecd210ba5c0bd869feaa555a?d=mp&s=160"},"body":"On Tue, Oct 30, 2007 at 07:59:45AM -0700, Linus Torvalds wrote:\n> > Not that I care, but git should probably handle things consistently.\n> \n> Git has been, and *is* entirely consistent. It uses convenient repo names. \n> If you don't want to call them url's, then call them \"repository name\". \n> Call them whatever. But they are 100% obvious, even if there are multiple \n> forms of them (and *none* of the forms do any quoting at all):\n> \n> - (\"origin\")\n> - (\"../git.git\")\n> - : (\"master.kernel.org:/pub/scm/...\")\n> - :/// (\"git://repo.or.cz/...\")\n> \n> See? We may not follow RFC's, but we follow \"easy to use\".\n\nWell, only the last one actually looks like a URL, so that is the only this\ndiscussion is about. I don't think anyone is suggesting that the first three\nbe changed at all. So, to use your terminology, git has a variety of ways to\nspecify a repo name, one of which happens to be a URL (or looks like one). The\nsuggestion is that we should make that way (and only that way) behave like a\nRFC URL.\n\nAnd git should be consistent with web browsers, automatically quoting things\nit gets passed. I think the only point of contention is probably how to deal\nwith URLs that git receives that are already quoted.\n\n1. We ignore the quoting and re-encode everything for the http transport.\n2. We honour the encoding and decode everything for the git transport.\n3. We handle git:// and http:// different, so that the three git:// URLs below\nrefer to different repositories, while the three http:// URLs give refer to\nthe same repository.\n\n> > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git\n> > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git\n> > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git\n> \n> > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git\n> > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git\n> > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git\n\nThe third possibility is probably what we do now, which is why I am suggesting\ngit is inconsistent. The first will fall down when using a repository that is\ncolocated, and somebody copies a URL from the web browsers location bar (which\nwill be properly encoded). Which leaves the second.\n\n Tom\n"},{"id":"57552","messageId":"alpine.LFD.0.999.0710301037120.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"20071030160232.GB2640@hermes.priv","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-30T17:39:03Z","receivedAt":"2007-10-30T17:39:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 30 Oct 2007, Tom Prince wrote:\n> >\n> > - (\"origin\")\n> > - (\"../git.git\")\n> > - : (\"master.kernel.org:/pub/scm/...\")\n> > - :/// (\"git://repo.or.cz/...\")\n> >\n> > See? We may not follow RFC's, but we follow \"easy to use\".\n>\n> Well, only the last one actually looks like a URL, so that is the only this\n> discussion is about.\n\nNO.\n\nThe thing is, we'd be much better off being consistent with OURSELVES than\nwith something else!\n\nNobody cares about git being consistent with a web browser. There is\nnothing in common.\n\nBut I *do* care about git being consistent with itself. If I do\n\n\tgit clone /some/directory\n\nand then decide that I want to generate a new pack and change it into\n\n\tgit clone file:///some/directory\n\nI don't want to have to re-write the thing to quote differently!\n\nThe same very much goes for a path like\n\n\tgit://git.kernel.org/\n\nvs\n\n\tmaster.kernel.org:\n\nbecause I will use the two interchangably. They *are* the same address,\nexcept:\n\n - the \"git://\" protocol is a bit faster, since the ssh connection\n overhead is actually big enough to be quite noticeable.\n\n - but I often use the master.kernel.org: thing because there's a\n mirroring delay that means that accessing it directly is sometimes\n preferable.\n\nSee? THAT is where we need to be consistent: with our own paths!\n\n[ And yes, I literally really do switch things around exactly like that \n between ssh accesses and the git:// protocol. That was not a made-up \n example, but real usage! ]\n\nIn contrast, nobody has _ever_ given a real technical reason to care about\nthe Web URL RFC at all.\n\nReally. It's that simple: if you cannot argue for something without\npointing to an irrelevant standard, you really shouldn't argue for it in\nthe first place.\n\nPeople who make decisions based on \"it's a standard\" make *sub*standard\ndecisions. The fact is, most standards are not worth even using as toilet\npaper, because they were designed by some committee that wanted to reach\n\"consensus\". That's just crap.\n\n Linus\n"},{"id":"57569","messageId":"vpq8x5kh4rr.fsf@bauges.imag.fr","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710301037120.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-10-30T17:49:12Z","receivedAt":"2007-10-30T17:49:12Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Linus Torvalds writes:\n\n> Nobody cares about git being consistent with a web browser.\n\nWhy do you keep talking about web browser?\n\nURLs are _not_ a web-browser thing. A web browser is just _one_\nexample of program which uses URLs.\n\n-- \nMatthieu\n"},{"id":"57582","messageId":"alpine.LFD.0.999.0710301056070.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"vpq8x5kh4rr.fsf@bauges.imag.fr","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-30T17:58:30Z","receivedAt":"2007-10-30T17:58:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 30 Oct 2007, Matthieu Moy wrote:\n>\n> Linus Torvalds writes:\n> \n> > Nobody cares about git being consistent with a web browser.\n> \n> Why do you keep talking about web browser?\n> \n> URLs are _not_ a web-browser thing. A web browser is just _one_\n> example of program which uses URLs.\n\nI keep talking about a web browser, because THE ONLY POINT of following a \nstandard is to interoperate.\n\nSo if you cannot find something to interoperate with, why the hell would \nyou care about the standard?\n\nSo here's a question: why do people bother to quote irrelevant RFC's?\n\nFollowing those RFC's would make git not interoperate WITH ITSELF, and use \nillogically different formats for the same things.\n\nSo if you want to make that RFC have any relevance what-so-ever, then show \nsome interoperability issue. Which is why I'm bringing up a web browser: \nthat interop issue simply *does*not*exist*.\n\nWhy is that so hard to understand?\n\n\t\t\tLinus\n"},{"id":"57589","messageId":"alpine.LFD.0.999.0710301100470.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710301056070.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-30T18:19:11Z","receivedAt":"2007-10-30T18:19:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 30 Oct 2007, Linus Torvalds wrote:\n> \n> So if you want to make that RFC have any relevance what-so-ever, then show \n> some interoperability issue. Which is why I'm bringing up a web browser: \n> that interop issue simply *does*not*exist*.\n\nBtw, the reason I care is that the whole \".. but it's a standard\" thinking \nreally is dangerous. It's how you create absolute and utter crap.\n\nIt's why I have also brought up XML in this discussion, because XML is a \nclassic example of something where this \".. but it's a standard\" thinking \nhas resulted in really bad solutions. It's pushed as a way to \n\"interoperate\", but then, since everybody does different things, the only \nthing you can actually interoperate with is by having a common parsing \nlibrary for a REALLY HORRIBLY BAD FORMAT!\n\nThe same is true of a URL. What is there to interoperate with? The whole \n(and only) point of the git remote URL is to point git to a different git \nrepository. There's no other reason to use it. So the only possible case \nwe care about interoperability is with other git uses.\n\nAnd those other git uses are not RFC1738-quoted, are they? \n\n\t\t\tLinus\n"},{"id":"57603","messageId":"472782CF.5050308@obry.net","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710301037120.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Pascal Obry","fromEmail":"pascal@obry.net","sentAt":"2007-10-30T19:15:27Z","receivedAt":"2007-10-30T19:15:27Z","isPatch":false,"sender":{"key":"pascal@obry.net","avatar":"https://avatars.githubusercontent.com/u/467069?v=4"},"body":"Linus Torvalds a écrit :\n> Nobody cares about git being consistent with a web browser. There is\n> nothing in common.\n\nI don't understand why you keep talking about web browser. URL is not a\nweb browser thing. It is the case that web browser are using URL, but\nthat's just one usage.\n\nPascal.\n\n-- \n\n--|------------------------------------------------------\n--| Pascal Obry Team-Ada Member\n--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE\n--|------------------------------------------------------\n--| http://www.obry.net\n--| \"The best way to travel is by means of imagination\"\n--|\n--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595\n"},{"id":"57624","messageId":"4727839B.9070205@obry.net","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710301056070.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Pascal Obry","fromEmail":"pascal@obry.net","sentAt":"2007-10-30T19:18:51Z","receivedAt":"2007-10-30T19:18:51Z","isPatch":false,"sender":{"key":"pascal@obry.net","avatar":"https://avatars.githubusercontent.com/u/467069?v=4"},"body":"Linus Torvalds a écrit :\n> I keep talking about a web browser, because THE ONLY POINT of following a \n> standard is to interoperate.\n\nYes, and since URLs are not used for web browser only I do not see the\npoint to concentrate all this discussion about a single possible usage.\n\n> Why is that so hard to understand?\n\nI'm thinking alike :)\n\nPascal;\n\n-- \n\n--|------------------------------------------------------\n--| Pascal Obry Team-Ada Member\n--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE\n--|------------------------------------------------------\n--| http://www.obry.net\n--| \"The best way to travel is by means of imagination\"\n--|\n--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595\n"},{"id":"57606","messageId":"20071030193610.GA4442@efreet.light.src","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710300738550.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-10-30T19:36:10Z","receivedAt":"2007-10-30T19:36:10Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Oct 30, 2007 at 07:59:45 -0700, Linus Torvalds wrote:\n> > So, how should git deal with\n> > \n> > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git\n> > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git\n> > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git\n> \n> The way it has always cared. Git itself does no quoting what-so-ever \n> (except for the *argument* quoting etc that it needs).\n> \n> Now, the *transport* back-end may end up quoting it, of course, the same \n> way it may end up using some random protocol. The user shouldn't care \n> about the implementation details!\n> \n> In the case of the git transport, there is no quoting even by the \n> transport protocol. In the case of http, libcurl would hopefully quote for \n> us.\n\nSo the three addresses will all be different, right?\n\n> > compared to \n> > \n> > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git\n> > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git\n> > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git\n> \n> No difference, what-so-ever, that I can see. Git doesn't quote it.\n\nYes. But the server will unquote it. ' ' should not have been there, but it's\njust passed through if it was. '+' is quoting for ' ' and '%20' is quoting\nfor ' ' as well. Therefore all these three addresses are the *SAME*.\n\nNow the user expectation will be that when these are the same, the git://\nones above will be as well. But they are not. This is not about following any\nRFC for sake of it, but about being consistent with ourselves.\n\n> Notice how the fact that we use http:// doesn't actually mean that you can \n> feed the result to a web browser anyway? It's not like you get a \"link\" \n> that git follows. You get a name.\n> \n> Yes, you can try to \"co-locate\" things so that something smart \n> disambiguates (maybe have an \"index.html\" file, so a web browser gets a \n> gitweb page, and git gets the raw data). But even then, notice how even \n> web browser will do the quoting for you: try\n> \n> \tfirefox \"http://www.google.com/search?q=Html spaces\"\n> \n> just for fun.\n\nSure. There is no abiguity in decoding this, so why refuse it.\n\n> [...]\n> - (\"origin\")\n> - (\"../git.git\")\n> - : (\"master.kernel.org:/pub/scm/...\")\n> - :/// (\"git://repo.or.cz/...\")\n> \n> See? We may not follow RFC's, but we follow \"easy to use\".\n\nThe first three don't look like URL (\"URL\" always means the thing defined by\nRFC 2396, at least to me), so I don't expect any quoting there. But for the\nlast case http:// (and for that matter, sftp://) do use quoting, so I would\nexpect the quoting of something that differs only by starting with git:// to\nwork the same. \n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"57604","messageId":"alpine.LFD.0.999.0710301232000.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"4727839B.9070205@obry.net","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-30T19:38:27Z","receivedAt":"2007-10-30T19:38:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 30 Oct 2007, Pascal Obry wrote:\n\n> Linus Torvalds a écrit :\n> > I keep talking about a web browser, because THE ONLY POINT of following a \n> > standard is to interoperate.\n> \n> Yes, and since URLs are not used for web browser only I do not see the\n> point to concentrate all this discussion about a single possible usage.\n\nHey, it's find if you can come up with some *other* case why we should \ncare about RFC 1738.\n\nI certainly didn't mean to bring up browsers as the _only_ case of \npossible interoperability issues, but when it comes to URL's it's \ncertainly the obvious one...\n\nSo the only argument really is:\n\n - Nobody has pointed to *any* reason to follow 1738.\n\n - I have pointed to reasons *not* to do it.\n\nSo if you want to follow the RFC, you'd better give a real reason. And no, \nthe existence of an RFC, and the fact that people use the same name for \nthings that superficially _look_ the same is not a reason in itself.\n\nSo hands up, people. Anybody who asked for RFC quoting. Give a damn \n*reason* already!\n\n\t\t\tLinus\n"},{"id":"57609","messageId":"alpine.LFD.0.999.0710301252240.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"20071030193610.GA4442@efreet.light.src","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-30T19:53:21Z","receivedAt":"2007-10-30T19:53:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 30 Oct 2007, Jan Hudec wrote:\n> > \n> > Now, the *transport* back-end may end up quoting it, of course, the same \n> > way it may end up using some random protocol. The user shouldn't care \n> > about the implementation details!\n> \n> Yes. But the server will unquote it. ' ' should not have been there, but it's\n> just passed through if it was. '+' is quoting for ' ' and '%20' is quoting\n> for ' ' as well. Therefore all these three addresses are the *SAME*.\n\nOk, you have some reading comprehension skills.\n\nRead the above again.\n\nI'd certainly hope that *curl* does the proper quoting. That's a transport \nissue.\n\n\t\tLinus\n"},{"id":"57613","messageId":"86tzo81hrd.fsf@blue.stonehenge.com","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710301232000.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-10-30T20:15:18Z","receivedAt":"2007-10-30T20:15:18Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\nLinus> So the only argument really is:\n\nLinus> - Nobody has pointed to *any* reason to follow 1738.\n\nLinus> - I have pointed to reasons *not* to do it.\n\nI can support non-compliance with 1738. However, I'd also suggest\nthat outside of this cozy group of developers, URL already has a heavily\ndefined meaning associated with 1738.\n\nTherefore, I propose that the git docs refrain from calling these things\n\"URLs\" because they're not, and instead adopt something like \"GRL\" (git\nresources locator) or whatever.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"57616","messageId":"alpine.LFD.0.999.0710301324390.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"86tzo81hrd.fsf@blue.stonehenge.com","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-30T20:30:50Z","receivedAt":"2007-10-30T20:30:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 30 Oct 2007, Randal L. Schwartz wrote:\n> \n> Therefore, I propose that the git docs refrain from calling these things\n> \"URLs\" because they're not, and instead adopt something like \"GRL\" (git\n> resources locator) or whatever.\n\nThey're called \"GIT URLS\" right now. I'd have hoped that was descriptive \nenough. But maybe not.\n\nI think it's stupid to make up a new name, it's not like it's really \nambiguous *or* as if people really think in terms of RFC's.\n\nLet's face it: people talk and use email, even when they don't have a clue \nabout SMTP. And in practice, you'll never see any difference, apart from \nthe obvious extension of using the ssh format and the direct local path \nthing.\n\n\t\tLinus\n"},{"id":"57617","messageId":"alpine.LFD.0.9999.0710301631150.21255@xanadu.home","threadId":"10294","inReplyTo":"86tzo81hrd.fsf@blue.stonehenge.com","subject":"Re: remote#branch","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-30T20:36:08Z","receivedAt":"2007-10-30T20:36:08Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 30 Oct 2007, Randal L. Schwartz wrote:\n\n> >>>>> \"Linus\" == Linus Torvalds writes:\n> \n> Linus> So the only argument really is:\n> \n> Linus> - Nobody has pointed to *any* reason to follow 1738.\n> \n> Linus> - I have pointed to reasons *not* to do it.\n> \n> I can support non-compliance with 1738. However, I'd also suggest\n> that outside of this cozy group of developers, URL already has a heavily\n> defined meaning associated with 1738.\n> \n> Therefore, I propose that the git docs refrain from calling these things\n> \"URLs\" because they're not, and instead adopt something like \"GRL\" (git\n> resources locator) or whatever.\n\nAnd what do you do with the remote..url config option?\nAdd some backward compatibility cruft for some... well... issue that \nturns out not to be one in practice?\n\nAgain, can someone point to a real usage scenario where all this \ndiscussion is solving something?\n\n\nNicolas\n"},{"id":"57626","messageId":"20071030235823.GA22747@coredump.intra.peff.net","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710301232000.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-30T23:58:23Z","receivedAt":"2007-10-30T23:58:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:\n\n> So if you want to follow the RFC, you'd better give a real reason. And no, \n> the existence of an RFC, and the fact that people use the same name for \n> things that superficially _look_ the same is not a reason in itself.\n> \n> So hands up, people. Anybody who asked for RFC quoting. Give a damn \n> *reason* already!\n\nI didn't ask for RFC quoting, but a nice side effect of URL syntax is\nthat they are machine parseable. If you wanted to write a tool to pick\nthe URLs out of this email and clone them as git repos, then how do you\nfind the end of:\n\n http://host/git repo with spaces in the path\n\ncompared to:\n\n http://host/git+repo+with+spaces+in+the+path\n\nI don't know if that's worth changing anything in git (in fact, I'm not\neven clear on _what_ people want to change; the point of this discussion\nseems to be to argue about terminology). But you did ask for any reason\nfor quoting URLs.\n\n-Peff\n"},{"id":"57631","messageId":"fg8h9l$b4n$1@ger.gmane.org","threadId":"10294","inReplyTo":"20071030235823.GA22747@coredump.intra.peff.net","subject":"Re: remote#branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-31T00:12:37Z","receivedAt":"2007-10-31T00:12:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King wrote:\n\n> On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:\n> \n>> So if you want to follow the RFC, you'd better give a real reason. And no, \n>> the existence of an RFC, and the fact that people use the same name for \n>> things that superficially _look_ the same is not a reason in itself.\n>> \n>> So hands up, people. Anybody who asked for RFC quoting. Give a damn \n>> *reason* already!\n> \n> I didn't ask for RFC quoting, but a nice side effect of URL syntax is\n> that they are machine parseable. If you wanted to write a tool to pick\n> the URLs out of this email and clone them as git repos, then how do you\n> find the end of:\n> \n> http://host/git repo with spaces in the path\n> \n> compared to:\n> \n> http://host/git+repo+with+spaces+in+the+path\n> \n> I don't know if that's worth changing anything in git (in fact, I'm not\n> even clear on _what_ people want to change; the point of this discussion\n> seems to be to argue about terminology). But you did ask for any reason\n> for quoting URLs.\n\nYou use\n\n 'http://host/git repo with spaces in the path'\n\nTheoretically, we can follow what other CLI tools dealing with URLs do\n(like wget, lynx, ...), i.e. assume that URL is _not_ RFC-escaped if it\nis in quotes, and assume that URL is properly escaped if it is not quoted.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"57635","messageId":"46a038f90710301741n67526976vda1cd131270aa7f@mail.gmail.com","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710292150400.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-10-31T00:41:12Z","receivedAt":"2007-10-31T00:41:12Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/30/07, Linus Torvalds wrote:\n> Quick! WHO THE F*CK CARES?\n\nAh, damn. In all the discussion & flamefesting to say that people\ndon't want to use the # character, noone talks about of what cogito\nused it for.\n\nHaving something functionally similar to\n\n cg-clone git://foo.tld/bar.git#blue\n\nwould save a few steps -- and some potential confusion -- for projects\nusing GIT.\n\nIn case it's not clear what it does (not everyone here has used\ncogito) it will create and checkout a branch tracking the \"blue\" head\non the repo when the clone is done. This is _instead of_ creating and\nchecking out the branch that tracks the configured \"HEAD\" of the repo.\n\nIMHO is a quite nice thing to have -- and AFAICS we don't have it in\nmaster or pu. I care about the shed for the bike, not its colour.\ncheers,\n\n\nm\n"},{"id":"57636","messageId":"alpine.LFD.0.999.0710301752250.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"46a038f90710301741n67526976vda1cd131270aa7f@mail.gmail.com","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-31T00:59:37Z","receivedAt":"2007-10-31T00:59:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 31 Oct 2007, Martin Langhoff wrote:\n> \n> Having something functionally similar to\n> \n> cg-clone git://foo.tld/bar.git#blue\n> \n> would save a few steps -- and some potential confusion -- for projects\n> using GIT.\n\nI do agree with that \"functionally similar\", I just disagree with the \nsyntax.\n\nThe thing is, we don't want a single branch name. Not for clone, not for \nfetch, not for pull, and not for push.\n\nYes, a single branch may be one common case, but it's definitely not the \nonly one, and it's fundamentally the wrong thing to use as a definition of \nsyntax. \n\nIt's also the wrong thing to do for local stuff.\n\n\t\t\tLinus\n"},{"id":"57637","messageId":"20071031013856.GA23274@coredump.intra.peff.net","threadId":"10294","inReplyTo":"fg8h9l$b4n$1@ger.gmane.org","subject":"Re: remote#branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-31T01:38:56Z","receivedAt":"2007-10-31T01:38:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 31, 2007 at 01:12:37AM +0100, Jakub Narebski wrote:\n\n> > that they are machine parseable. If you wanted to write a tool to pick\n> > the URLs out of this email and clone them as git repos, then how do you\n> > find the end of:\n> > \n> > http://host/git repo with spaces in the path\n> You use\n> \n> 'http://host/git repo with spaces in the path'\n\n...which is a quoting mechanism, and it's not even one commonly used in\nemails (i.e., people have written \"parse a URL from this text\" scripts\nfor RFC-encoded URLs, but _not_ for shell quoting).\n\n-Peff\n"},{"id":"57638","messageId":"20071031014347.GB23274@coredump.intra.peff.net","threadId":"10294","inReplyTo":"46a038f90710301741n67526976vda1cd131270aa7f@mail.gmail.com","subject":"Re: remote#branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-31T01:43:47Z","receivedAt":"2007-10-31T01:43:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 31, 2007 at 01:41:12PM +1300, Martin Langhoff wrote:\n\n> Having something functionally similar to\n> \n> cg-clone git://foo.tld/bar.git#blue\n> \n> would save a few steps -- and some potential confusion -- for projects\n> using GIT.\n> \n> In case it's not clear what it does (not everyone here has used\n> cogito) it will create and checkout a branch tracking the \"blue\" head\n> on the repo when the clone is done. This is _instead of_ creating and\n> checking out the branch that tracks the configured \"HEAD\" of the repo.\n\nActually, IIRC it won't fetch any of the non 'blue' refs.\n\nAnyway, to recap (my impression of) the discussion leading up to this:\n - the cogito feature is useful\n - the cogito syntax does not allow for multiple branches to be\n specified\n - one such syntax proposed was git://foo.tld/bar.git#blue,red\n - one problem with that syntax is that comma is a valid character\n in the branch name, and '#' is a valid character in the repo name\n - one proposed solution was that '#' and ',' when used as data should\n be URL-encoded\n - flamefest begin\n\nSo I think nobody disagrees that such a feature is useful; there is\ndisagreement about the syntax.\n\n-Peff\n"},{"id":"57639","messageId":"200710310249.17233.jnareb@gmail.com","threadId":"10294","inReplyTo":"20071031013856.GA23274@coredump.intra.peff.net","subject":"Re: remote#branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-31T01:49:16Z","receivedAt":"2007-10-31T01:49:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King wrote:\n> On Wed, Oct 31, 2007 at 01:12:37AM +0100, Jakub Narebski wrote:\n> \n>>> that they are machine parseable. If you wanted to write a tool to pick\n>>> the URLs out of this email and clone them as git repos, then how do you\n>>> find the end of:\n>>> \n>>> http://host/git repo with spaces in the path\n>>\n>> You use\n>> \n>> 'http://host/git repo with spaces in the path'\n> \n> ...which is a quoting mechanism, and it's not even one commonly used in\n> emails (i.e., people have written \"parse a URL from this text\" scripts\n> for RFC-encoded URLs, but _not_ for shell quoting).\n\nI don't think RFC-encoding is quoting mechanism used in emails, either.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"57640","messageId":"46a038f90710301849h1c31736an1ec163aa1e274577@mail.gmail.com","threadId":"10294","inReplyTo":"20071031014347.GB23274@coredump.intra.peff.net","subject":"Re: remote#branch","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-10-31T01:49:49Z","receivedAt":"2007-10-31T01:49:49Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/31/07, Jeff King wrote:\n> Actually, IIRC it won't fetch any of the non 'blue' refs.\n\nYou recall correctly, and that was a cogito misfeature. I don't think\ngit should follow that part of the spec ;-)\n\n> Anyway, to recap (my impression of) the discussion leading up to this:\n> - the cogito feature is useful\n...\n> - flamefest begin\n\nGreat summary. I read the first and last stages you describe (with a\ntrip in the middle distracting me). Heh.\n\nNo stress. Let the flames continue!\n\n\nm\n"},{"id":"57641","messageId":"20071031015708.GA24403@coredump.intra.peff.net","threadId":"10294","inReplyTo":"200710310249.17233.jnareb@gmail.com","subject":"Re: remote#branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-31T01:57:08Z","receivedAt":"2007-10-31T01:57:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:\n\n> > ...which is a quoting mechanism, and it's not even one commonly used in\n> > emails (i.e., people have written \"parse a URL from this text\" scripts\n> > for RFC-encoded URLs, but _not_ for shell quoting).\n> \n> I don't think RFC-encoding is quoting mechanism used in emails, either.\n\nThat's funny, because I have hundreds of mails where that is the case,\nand none where people used shell-quoting. Most URLs don't _need_ any\nencoding, so we don't notice either way. But are you honestly telling me\nthat if you needed to communicate a URL with a space via email, you\nwould write:\n\n 'http://foo.tld/url with a space'\n\nrather than:\n\n http://foo.tld/url+with+a+space\n\n?\n\nI think the latter is much more common, if only because of the fact that\ncopy and paste from most browsers' location bars gives the encoded\nversion.\n\n-Peff\n"},{"id":"57642","messageId":"20071031015938.GB24403@coredump.intra.peff.net","threadId":"10294","inReplyTo":"46a038f90710301849h1c31736an1ec163aa1e274577@mail.gmail.com","subject":"Re: remote#branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-31T01:59:38Z","receivedAt":"2007-10-31T01:59:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 31, 2007 at 02:49:49PM +1300, Martin Langhoff wrote:\n\n> > Actually, IIRC it won't fetch any of the non 'blue' refs.\n> You recall correctly, and that was a cogito misfeature. I don't think\n> git should follow that part of the spec ;-)\n\nI'm not so sure. Junio keeps unrelated branches in git.git like 'html'\nand 'todo'. Is it unreasonable to say \"clone git.git, but only the todo\nbranch\" and expect it _not_ to download the entire git history?\n\n-Peff\n"},{"id":"57651","messageId":"Pine.LNX.4.64.0710310304180.4362@racer.site","threadId":"10294","inReplyTo":"20071031014347.GB23274@coredump.intra.peff.net","subject":"Re: remote#branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-31T03:08:32Z","receivedAt":"2007-10-31T03:08:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Oct 2007, Jeff King wrote:\n\n> Anyway, to recap (my impression of) the discussion leading up to this:\n> - the cogito feature is useful\n> - the cogito syntax does not allow for multiple branches to be\n> specified\n\nHere somebody else than me (IIRC Junio) proposed this syntax:\n\n\tgit clone --track [--track ] \n\nNobody was interested enough to implement it.\n\nI then proposed delimiting with spaces, since they were _not part of a \nURL_:\n\n\tgit clone \" \"\n\nbut some people insisted on \"#\", which I pointed out (several times!) is a \nno go, and I actually provided reasons for that.\n\n> - one such syntax proposed was git://foo.tld/bar.git#blue,red\n> - one problem with that syntax is that comma is a valid character\n> in the branch name, and '#' is a valid character in the repo name\n> - one proposed solution was that '#' and ',' when used as data should\n> be URL-encoded\n> - flamefest begin\n> \n> So I think nobody disagrees that such a feature is useful; there is\n> disagreement about the syntax.\n\nProbably there is not enough need, too, and the discussion will peter out \nagain, without anybody letting some code talk, and I will not make the \nmistake again of reviving this discussion. Promise.\n\nCiao,\nDscho\n"},{"id":"57660","messageId":"85pryvzt1h.fsf@lola.goethe.zz","threadId":"10294","inReplyTo":"20071030235823.GA22747@coredump.intra.peff.net","subject":"Re: remote#branch","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-31T06:39:54Z","receivedAt":"2007-10-31T06:39:54Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King writes:\n\n> On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:\n>\n>> So if you want to follow the RFC, you'd better give a real reason. And no, \n>> the existence of an RFC, and the fact that people use the same name for \n>> things that superficially _look_ the same is not a reason in itself.\n>> \n>> So hands up, people. Anybody who asked for RFC quoting. Give a damn \n>> *reason* already!\n>\n> I didn't ask for RFC quoting, but a nice side effect of URL syntax is\n> that they are machine parseable. If you wanted to write a tool to pick\n> the URLs out of this email and clone them as git repos, then how do you\n> find the end of:\n>\n> http://host/git repo with spaces in the path\n>\n> compared to:\n>\n> http://host/git+repo+with+spaces+in+the+path\n\nYou just write and\nhave a good chance it will work.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"57661","messageId":"85lk9jzsxb.fsf@lola.goethe.zz","threadId":"10294","inReplyTo":"fg8h9l$b4n$1@ger.gmane.org","subject":"Re: remote#branch","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-31T06:42:24Z","receivedAt":"2007-10-31T06:42:24Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jakub Narebski writes:\n\n> Jeff King wrote:\n>\n>> On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:\n>> \n>> http://host/git repo with spaces in the path\n>> \n>> compared to:\n>> \n>> http://host/git+repo+with+spaces+in+the+path\n>> \n>> I don't know if that's worth changing anything in git (in fact, I'm not\n>> even clear on _what_ people want to change; the point of this discussion\n>> seems to be to argue about terminology). But you did ask for any reason\n>> for quoting URLs.\n>\n> You use\n>\n> 'http://host/git repo with spaces in the path'\n\nI can click on links in my mail reader, and the above is not recognized\nas one. would likely\nwork.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"57662","messageId":"47282A0D.9010400@op5.se","threadId":"10294","inReplyTo":"20071031015708.GA24403@coredump.intra.peff.net","subject":"Re: remote#branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-31T07:09:01Z","receivedAt":"2007-10-31T07:09:01Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jeff King wrote:\n> On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:\n> \n>>> ...which is a quoting mechanism, and it's not even one commonly used in\n>>> emails (i.e., people have written \"parse a URL from this text\" scripts\n>>> for RFC-encoded URLs, but _not_ for shell quoting).\n>> I don't think RFC-encoding is quoting mechanism used in emails, either.\n> \n> That's funny, because I have hundreds of mails where that is the case,\n> and none where people used shell-quoting. Most URLs don't _need_ any\n> encoding, so we don't notice either way. But are you honestly telling me\n> that if you needed to communicate a URL with a space via email, you\n> would write:\n> \n> 'http://foo.tld/url with a space'\n> \n> rather than:\n> \n> http://foo.tld/url+with+a+space\n> \n> ?\n> \n\nI think 99% of all URL's communicated via email are copy-pasted from a\nwebbrowsers location bar. I believe most git urls (or grls, or whatever\nyou wanna call them) communicated via email are copy-pasted from ones\nconfig, or written out manually.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57666","messageId":"1D1C13E6-EC4C-4C2E-BDA1-F04CAA23A3CC@wincent.com","threadId":"10294","inReplyTo":"85pryvzt1h.fsf@lola.goethe.zz","subject":"Re: remote#branch","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-31T08:16:01Z","receivedAt":"2007-10-31T08:16:01Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 31/10/2007, a las 7:39, David Kastrup escribió:\n\n> Jeff King writes:\n>\n>> I didn't ask for RFC quoting, but a nice side effect of URL syntax is\n>> that they are machine parseable. If you wanted to write a tool to \n>> pick\n>> the URLs out of this email and clone them as git repos, then how do \n>> you\n>> find the end of:\n>>\n>> http://host/git repo with spaces in the path\n>>\n>> compared to:\n>>\n>> http://host/git+repo+with+spaces+in+the+path\n>\n> You just write and\n> have a good chance it will work.\n\nAs a data point, my email client correctly highlights only this one as \na URL:\n\nhttp://host/git+repo+with+spaces+in+the+path\n\nBoth of these are incorrectly highlighted:\n\nhttp://host/git repo with spaces in the path\n\n\nAnd this one too:\n\n\n\nSo what does this mean in practice? I can right-click on the first one \nand choose \"Copy\". All the other ones I have to left-click and drag, \nbeing careful to limit the selection to the appropriate left and right \nboundaries.\n\nWhether or not this is a big enough deal to actually care about is \nopen to debate (obviously). Personally, I don't care too much seeing \nas I never use paths with spaces in them for this kind of thing.\n\nCheers,\nWincent\n"},{"id":"57667","messageId":"200710310925.56607.robin.rosenberg.lists@dewire.com","threadId":"10294","inReplyTo":"85pryvzt1h.fsf@lola.goethe.zz","subject":"Re: remote#branch","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-10-31T08:25:54Z","receivedAt":"2007-10-31T08:25:54Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 31 oktober 2007 skrev David Kastrup:\n> Jeff King writes:\n> \n> > On Tue, Oct 30, 2007 at 12:38:27PM -0700, Linus Torvalds wrote:\n> >\n> >> So if you want to follow the RFC, you'd better give a real reason. And no, \n> >> the existence of an RFC, and the fact that people use the same name for \n> >> things that superficially _look_ the same is not a reason in itself.\n> >> \n> >> So hands up, people. Anybody who asked for RFC quoting. Give a damn \n> >> *reason* already!\n> >\n> > I didn't ask for RFC quoting, but a nice side effect of URL syntax is\n> > that they are machine parseable. If you wanted to write a tool to pick\n> > the URLs out of this email and clone them as git repos, then how do you\n> > find the end of:\n> >\n> > http://host/git repo with spaces in the path\n> >\n> > compared to:\n> >\n> > http://host/git+repo+with+spaces+in+the+path\n> \n> You just write and\n> have a good chance it will work.\n\nIt doesn't with KMail.\n\n-- robin\n"},{"id":"57669","messageId":"20071031083506.GA23316@glandium.org","threadId":"10294","inReplyTo":"47282A0D.9010400@op5.se","subject":"Re: remote#branch","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-10-31T08:35:06Z","receivedAt":"2007-10-31T08:35:06Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Wed, Oct 31, 2007 at 08:09:01AM +0100, Andreas Ericsson wrote:\n> Jeff King wrote:\n> >On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:\n> >\n> >>>...which is a quoting mechanism, and it's not even one commonly used in\n> >>>emails (i.e., people have written \"parse a URL from this text\" scripts\n> >>>for RFC-encoded URLs, but _not_ for shell quoting).\n> >>I don't think RFC-encoding is quoting mechanism used in emails, either.\n> >\n> >That's funny, because I have hundreds of mails where that is the case,\n> >and none where people used shell-quoting. Most URLs don't _need_ any\n> >encoding, so we don't notice either way. But are you honestly telling me\n> >that if you needed to communicate a URL with a space via email, you\n> >would write:\n> >\n> > 'http://foo.tld/url with a space'\n> >\n> >rather than:\n> >\n> > http://foo.tld/url+with+a+space\n> >\n> >?\n> >\n> \n> I think 99% of all URL's communicated via email are copy-pasted from a\n> webbrowsers location bar. I believe most git urls (or grls, or whatever\n> you wanna call them) communicated via email are copy-pasted from ones\n> config, or written out manually.\n\nOr copied from gitweb.\n\nMike\n"},{"id":"57672","messageId":"472844D4.8050306@op5.se","threadId":"10294","inReplyTo":"20071031083506.GA23316@glandium.org","subject":"Re: remote#branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-31T09:03:16Z","receivedAt":"2007-10-31T09:03:16Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Mike Hommey wrote:\n> On Wed, Oct 31, 2007 at 08:09:01AM +0100, Andreas Ericsson wrote:\n>> Jeff King wrote:\n>>> On Wed, Oct 31, 2007 at 02:49:16AM +0100, Jakub Narebski wrote:\n>>>\n>>>>> ...which is a quoting mechanism, and it's not even one commonly used in\n>>>>> emails (i.e., people have written \"parse a URL from this text\" scripts\n>>>>> for RFC-encoded URLs, but _not_ for shell quoting).\n>>>> I don't think RFC-encoding is quoting mechanism used in emails, either.\n>>> That's funny, because I have hundreds of mails where that is the case,\n>>> and none where people used shell-quoting. Most URLs don't _need_ any\n>>> encoding, so we don't notice either way. But are you honestly telling me\n>>> that if you needed to communicate a URL with a space via email, you\n>>> would write:\n>>>\n>>> 'http://foo.tld/url with a space'\n>>>\n>>> rather than:\n>>>\n>>> http://foo.tld/url+with+a+space\n>>>\n>>> ?\n>>>\n>> I think 99% of all URL's communicated via email are copy-pasted from a\n>> webbrowsers location bar. I believe most git urls (or grls, or whatever\n>> you wanna call them) communicated via email are copy-pasted from ones\n>> config, or written out manually.\n> \n> Or copied from gitweb.\n> \n\nPerhaps, but I've never seen that done. Partly because you can't be sure\nthe HTTP url is the same as the git address (perhaps people are used to\nthis from CVS and the likes), and partly because you'd, for most cases,\nwant to use git:// or ssh transport instead of http.\n\nIt might be nifty to have gitweb print some git-valid locator for a repo\nthough, or even a full copy-pastable \"git clone git://host/path/to/repo.git\"\ncommand-line thingie. I'll look into it when I have leisure.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57674","messageId":"20071031091529.GA25025@glandium.org","threadId":"10294","inReplyTo":"472844D4.8050306@op5.se","subject":"Re: remote#branch","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-10-31T09:15:29Z","receivedAt":"2007-10-31T09:15:29Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson wrote:\n> >Or copied from gitweb.\n> >\n> \n> Perhaps, but I've never seen that done. Partly because you can't be sure\n> the HTTP url is the same as the git address (perhaps people are used to\n> this from CVS and the likes), and partly because you'd, for most cases,\n> want to use git:// or ssh transport instead of http.\n> \n> It might be nifty to have gitweb print some git-valid locator for a repo\n> though, or even a full copy-pastable \"git clone git://host/path/to/repo.git\"\n> command-line thingie. I'll look into it when I have leisure.\n\nHum... it already does print http and git \"Mirror URL\"s which are ready to\nbe copy/pasted to feed git clone arguments.\n\nMike\n"},{"id":"57675","messageId":"47284BD4.5050904@obry.net","threadId":"10294","inReplyTo":"20071031015708.GA24403@coredump.intra.peff.net","subject":"Re: remote#branch","fromName":"Pascal Obry","fromEmail":"pascal@obry.net","sentAt":"2007-10-31T09:33:08Z","receivedAt":"2007-10-31T09:33:08Z","isPatch":false,"sender":{"key":"pascal@obry.net","avatar":"https://avatars.githubusercontent.com/u/467069?v=4"},"body":"Jeff King a écrit :\n> 'http://foo.tld/url with a space'\n> \n> rather than:\n> \n> http://foo.tld/url+with+a+space\n> \n> ?\n> \n> I think the latter is much more common, if only because of the fact that\n> copy and paste from most browsers' location bars gives the encoded\n> version.\n\nI agree 100%. It is the more common as it follows the standard encoding.\n\nPascal.\n\n-- \n\n--|------------------------------------------------------\n--| Pascal Obry Team-Ada Member\n--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE\n--|------------------------------------------------------\n--| http://www.obry.net\n--| \"The best way to travel is by means of imagination\"\n--|\n--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595\n"},{"id":"57676","messageId":"47284C43.1030007@obry.net","threadId":"10294","inReplyTo":"85pryvzt1h.fsf@lola.goethe.zz","subject":"Re: remote#branch","fromName":"Pascal Obry","fromEmail":"pascal@obry.net","sentAt":"2007-10-31T09:34:59Z","receivedAt":"2007-10-31T09:34:59Z","isPatch":false,"sender":{"key":"pascal@obry.net","avatar":"https://avatars.githubusercontent.com/u/467069?v=4"},"body":"David Kastrup a écrit :\n> You just write and\n> have a good chance it will work.\n\nWell \"good chance\" is not an option for reliable software :)\n\nPascal.\n\n-- \n\n--|------------------------------------------------------\n--| Pascal Obry Team-Ada Member\n--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE\n--|------------------------------------------------------\n--| http://www.obry.net\n--| \"The best way to travel is by means of imagination\"\n--|\n--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595\n"},{"id":"57709","messageId":"alpine.LFD.0.999.0710310816180.30120@woody.linux-foundation.org","threadId":"10294","inReplyTo":"85lk9jzsxb.fsf@lola.goethe.zz","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-31T15:28:36Z","receivedAt":"2007-10-31T15:28:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 31 Oct 2007, David Kastrup wrote:\n> \n> I can click on links in my mail reader, and the above is not recognized\n> as one. would likely\n> work.\n\nI don't think this whole discussion is relevant at all.\n\nWhy?\n\nBecause we don't care! This is *exactly* why I brought up the whole \ndiscussion about \"interoperability with a web browser\", and pointed out \nthat there is no such thing *anyway*, since a GIT URL is generally not \nsuitable for browsing _regardless_ of any encoding issues!\n\nSo it doesn't matter one whit if a mail client recognizes GIT URL's or \nnot! Because the mail client cannot do the right thing with them anyway, \nand would generally think that it's something that it should highlight so \nthat you can browse it!\n\nBesides, you generally shouldn't use http for git URL's in the first \nplace, and they are very much a secondary citizen. Yes, some people use \nthem because they have firewall issues, and they *work*, but giving them \nas examples of GIT URL's and discussing them as it they were a big deal is \njust *stupid* when no other - more realistic - git url works that way \nanyway.\n\nThis was the whole and only point of my \"interoperability\" thing. The GIT \nURL's - even when they are perfectly well-formed URL's (which is basically \n100% of the time, since no current git server tends to put things like \nspaces in the path anyway) - are simply in a different \"space\" than most \nother URL's.\n\nYou cannot feed them to a web browser or a file browser anyway, since the \nURL is actually mal-formed (on purpose) in *another* and more fundamental \nway: it doesn't say what the \"application domain\" is, since it basically \njust assumes that the application domain is git, and the \"scheme\" part of \nthe URL really talks only about the _protocol_, not about the fact that \nit's a git thing.\n\nSo if you wanted to be inter-operable, you'd have add the \"git\" part to \nthe scheme, and do the (insane, in my opinion) cogito thing with \n\"git+http://xyz.hjashja/\" thing!\n\nSee? Otherwise no non-git program could understand *anyway* that it's a \ngit address, and not meant to be some html thing.\n\nSo to summarise:\n\n - the only way to make git interoperate would be to be user-UNfriendly \n with stupid markers that no git program really needs or wants, and by \n making the escaping depend on the form of the GIT URL.\n\nBut hey, if people want to screw up git even more, and make the \"git+\" \ncrap also encode the address, I don't care. I would never *ever* use the \n\"git+xyz://\" forms anyway. They're stupid and useless, but if you want to \nhave programs automatically do something magical about git url's, you'd \nneed that \"git+\" thing.\n\nPersonally, I think it's a much better idea to just be git-specific. \nBecause realistically, nobody is ever going to really be anything else \nanyway. There is nothing you can sanely do with a git link, unless it's \nsomething very git specific and conscious in the first place!\n\n\t\t\tLinus\n"},{"id":"57713","messageId":"20071031170951.GR18279@machine.or.cz","threadId":"10294","inReplyTo":"2c6b72b30710161516j5c029847r1acb3ce2d88344a1@mail.gmail.com","subject":"Re: cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-10-31T17:09:51Z","receivedAt":"2007-10-31T17:09:51Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Oct 17, 2007 at 12:16:25AM +0200, Jonas Fonseca wrote:\n> On 10/16/07, Johannes Schindelin wrote:\n> > On Tue, 16 Oct 2007, Petr Baudis wrote:\n> > > I'm not sure this is good idea, Cogito is still quite frequently used\n> > > and it should be documented that it exists.\n> >\n> > I agree. But maybe it could be marked as unmaintained? Maybe someone\n> > steps up to maintain it. Or, even better, comes up with a list of \"this\n> > is what I like do regularly with cogito, but there's no easy way with core\n> > git\" issues.\n> \n> One thing that I occasionally miss is\n> \n> cg-export /path/to/directory/\n> \n> And yes, I know it can be accomplished via \"obscurities\" like\n> git-archive+tar (or worse git-checkout-index) but I think having\n> an easy way to checkout to a directory could be great (and possibly\n> with the ability to apply substitutions with the recent discussion).\n> \n> Else, I am really looking forward for the option parser work to provide\n> an easy way to list options. I found it very useful with Cogito.\n> Also, most of the \"status\" commands in Cogito seemd to provide a richer\n> default output geared towards human consumption. For example stuff like\n> git-branch -v and git remote -v flags would have been the default for\n> Cogito ... I think.\n\nA \"me too\" mail for once...\n\nI fully second this. cg-export is one of the Cogito commands I still use\nfrequently. I wonder if there is any obvious piece of Git command set we\ncould glue this on (so that we don't introduce Yet Another Command)... I\nthink cg-export is better-named here than git-archive. ;-)\n\nAnd some command in Git to easily get the equivalent of cg-status -g\noutput is something I probably miss the most in Git now. (Originally I\nwas about to say that I just miss an equivalent of cg-status, but\nthinking about it, most of the time I'm interested only in either -g\n(long branch info) or -w (git status output)).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nWe don't know who it was that discovered water, but we're pretty sure\nthat it wasn't a fish.\t\t-- Marshall McLuhan\n"},{"id":"57715","messageId":"20071031171308.GS18279@machine.or.cz","threadId":"10294","inReplyTo":"20071030235823.GA22747@coredump.intra.peff.net","subject":"Re: remote#branch","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-10-31T17:13:08Z","receivedAt":"2007-10-31T17:13:08Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Oct 30, 2007 at 07:58:23PM -0400, Jeff King wrote:\n> http://host/git repo with spaces in the path\n> \n> compared to:\n> \n> http://host/git+repo+with+spaces+in+the+path\n\nJust pedantic side-note: these two URLs are not equivalent. '+' is valid\nsubstitute for a space only in query string part of URL. In path you\nhave to use %20.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nWe don't know who it was that discovered water, but we're pretty sure\nthat it wasn't a fish.\t\t-- Marshall McLuhan\n"},{"id":"57719","messageId":"20071031192901.GA12832@localhost.localdomain","threadId":"10294","inReplyTo":"20071030193610.GA4442@efreet.light.src","subject":"Re: remote#branch","fromName":"Erik Warendorph","fromEmail":"erik@warendorph.org","sentAt":"2007-10-31T19:29:01Z","receivedAt":"2007-10-31T19:29:01Z","isPatch":false,"sender":{"key":"erik@warendorph.org","avatar":null},"body":"* Jan Hudec [2007-10-30 20:36:10 +0100]:\n>\n> On Tue, Oct 30, 2007 at 07:59:45 -0700, Linus Torvalds wrote:\n> > > So, how should git deal with\n> > >\n> > > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git\n> > > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git\n> > > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git\n> >\n> > The way it has always cared. Git itself does no quoting what-so-ever\n> > (except for the *argument* quoting etc that it needs).\n> >\n> > Now, the *transport* back-end may end up quoting it, of course, the same\n> > way it may end up using some random protocol. The user shouldn't care\n> > about the implementation details!\n> >\n> > In the case of the git transport, there is no quoting even by the\n> > transport protocol. In the case of http, libcurl would hopefully quote for\n> > us.\n>\n> So the three addresses will all be different, right?\n>\n> > > compared to\n> > >\n> > > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git\n> > > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git\n> > > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git\n> >\n> > No difference, what-so-ever, that I can see. Git doesn't quote it.\n>\n> Yes. But the server will unquote it. ' ' should not have been there, but it's\n> just passed through if it was. '+' is quoting for ' ' and '%20' is quoting\n> for ' ' as well. Therefore all these three addresses are the *SAME*.\n>\n> Now the user expectation will be that when these are the same, the git://\n> ones above will be as well. But they are not. This is not about following any\n> RFC for sake of it, but about being consistent with ourselves.\n\nI don't think the\n\n '+' is quoting for ' '\n\npart is fully correct, at least not if you're talking about\n\"real RFC 2396 URLs\" (not \"Git URLs\"). I might misunderstand\nyou here, but there has also been other postings suggesting\nthat plus should/could be used instead of space, implying that\npeople think that pluses are always transformed to spaces in\nURLs. But if I understand RFC 2396 correctly, this is *not*\nthe case.\n\nRFC 2396 says that pluses are treated as \"reserved\" in the\n*query* part of the URL (ie on the right side of the question\nmark) -- here they *are* transformed to spaces, although the\nRFC itself doesn't really say specifically what happens to\nthem. In the path part, pluses are not \"reserved\", they are\nsimply a \"pchar\" along with \"unreserved\", \"escaped\" and a\ncouple of other characters. There is nothing in the RFC\nimplying that pluses in the path part will be transformed into\nspaces, and in my experience this does not happen in practice\neither.\n\nTo recap:\n\n (In the examples below <...> is used to mean legal URLs,\n while \"...\" is used to mean \"the literal characters in the\n URL\" (more or less))\n\n * In the query part:\n\n '%20' = '+' = a literal space\n '%2B' = a literal plus\n\n For example:\n\n \n = \n = \"http://example.com/somescript?v=x y\"\n\n \n = \"http://example.com/somescript?v=x+y\"\n\n * In the path part:\n\n '%20' = a literal space\n '%2B' = '+' = a literal plus\n\n For example:\n\n \n = \"http://example.com/x y.html\"\n\n \n = \n = \"http://example.com/x+y\"\n\nI'm not advocating that \"Git URLs\" necessarily should be made\nfully RFC 2396 compliant (neither am I nitpicking just for the\nsake of nitpicking), I'm just pointing out that if someone\n*should* want to make \"Git URLs\" fully or more RFC 2396\ncompliant in some way for some reason, having pluses being\nautomatically transformed to spaces in the path part of the URL\ndoes not follow the RFC (as far as I understand it).\n\n-- \nErik Warendorph \n"},{"id":"57730","messageId":"20071031204729.GB13300@coredump.intra.peff.net","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710310816180.30120@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-31T20:47:29Z","receivedAt":"2007-10-31T20:47:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 31, 2007 at 08:28:36AM -0700, Linus Torvalds wrote:\n\n> Because we don't care! This is *exactly* why I brought up the whole \n> discussion about \"interoperability with a web browser\", and pointed out \n> that there is no such thing *anyway*, since a GIT URL is generally not \n> suitable for browsing _regardless_ of any encoding issues!\n> \n> So it doesn't matter one whit if a mail client recognizes GIT URL's or \n> not! Because the mail client cannot do the right thing with them anyway, \n> and would generally think that it's something that it should highlight so \n> that you can browse it!\n\nTwo points:\n\n 1. Just because _your_ mail client can't do anything useful with git\n URLs^H^H^H^H repo specifications, doesn't mean that others can't.\n\n 2. You are conflating syntax and semantics. Think of the task I\n mentioned as two subtasks: pulling the location specifier from the\n email, and then doing something useful with it (in this case,\n git-cloning it it). The first subtask depends _only_ on a parseable\n syntax. The user can provide the context necessary for accomplishing\n the second subtask.\n\nFor example, consider a terminal that, upon pressing some keyboard\ncombination, will highlight the first URL-ish looking blob on the\nscreen, prompt you for a command, and then execute '$command $url'. The\nterminal doesn't have to know the semantics of the blob, but it has to\nknow the syntax. The user provides the semantics.\n\nAnd yes, such a terminal exists, and I'm using it right now.\n\n> Besides, you generally shouldn't use http for git URL's in the first \n> place, and they are very much a secondary citizen. Yes, some people use \n> them because they have firewall issues, and they *work*, but giving them \n> as examples of GIT URL's and discussing them as it they were a big deal is \n> just *stupid* when no other - more realistic - git url works that way \n> anyway.\n\nThe example above is equally applicable to git:// URLs. As it is to\nhost:path specifiers, although obviously that is a syntax that the\nhighlighter would have to recognize. But the point is that by following\nestablished syntaxes, you don't have to write a git-repo-specifier\nsyntax parser; it comes for free (and isn't that, after all, the entire\n_point_ of URLs?).\n\n> This was the whole and only point of my \"interoperability\" thing. The GIT \n> URL's - even when they are perfectly well-formed URL's (which is basically \n> 100% of the time, since no current git server tends to put things like \n> spaces in the path anyway) - are simply in a different \"space\" than most \n> other URL's.\n\nSure, you need context to use them correctly. But that doesn't\nnecessarily mean you should just give up on the syntax part. I would\nrather the computer do half of the task and let me finish it than make\nme do the whole thing.\n\n> You cannot feed them to a web browser or a file browser anyway, since the \n> URL is actually mal-formed (on purpose) in *another* and more fundamental \n> way: it doesn't say what the \"application domain\" is, since it basically \n> just assumes that the application domain is git, and the \"scheme\" part of \n> the URL really talks only about the _protocol_, not about the fact that \n> it's a git thing.\n> \n> So if you wanted to be inter-operable, you'd have add the \"git\" part to \n> the scheme, and do the (insane, in my opinion) cogito thing with \n> \"git+http://xyz.hjashja/\" thing!\n\nYes, if you did that, you could automate _both_ parts of the task. But\nagain, that doesn't mean there isn't value to automating the first part\nBut that aside, even git+http doesn't solve all of your problems,\nbecause it doesn't say _what_ you want to do with the location. Web\nbrowsers just assume you want to fetch and view a location. But other\ntools which accept URLs might perform _other_ actions on a given\nlocation. So URLs really are a \"subject\" that can be operated on. It's\njust that we are most accustomed to seeing them used by the \"retrieve\nthis and display it\" tool.\n\n> - the only way to make git interoperate would be to be user-UNfriendly \n> with stupid markers that no git program really needs or wants, and by \n> making the escaping depend on the form of the GIT URL.\n\nSome git specifiers clearly look like URLs. Why not accept URL encoding\nfor them? And if there are characters that _should_ have been encoded by\nURL encoding standards, treat them as if they had been encoded (i.e.,\nhanding 'http://foo.tld/repo with space' would be treated the same as\n'http://foo.tld/repo%20with%20space'). This means that most unencoded\nrepos will behave exactly the same, but we are more liberal in wht we\naccept. The exception is that repos with a '%' in the specifier will\nparse differently (i.e., if you actually had a repo with the literal\ncharacters '%20' in it, it will no parse).\n\nYes, this means that if you have a bizarre repo name, you can't\nnecessarily switch between host:file syntax and git:// syntax by simple\ncut and paste. But you really can't _anyway_, since there is no\nguarantee that they are rooted at the same location, or have the same\nview of the filesystem.\n\n> Personally, I think it's a much better idea to just be git-specific. \n\nThen why in the world did you choose a specifier syntax that looks\n_exactly_ like a URL?\n\n-Peff\n"},{"id":"57732","messageId":"alpine.LFD.0.999.0710311350100.3342@woody.linux-foundation.org","threadId":"10294","inReplyTo":"20071031204729.GB13300@coredump.intra.peff.net","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-31T21:01:54Z","receivedAt":"2007-10-31T21:01:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 31 Oct 2007, Jeff King wrote:\n> \n> Yes, this means that if you have a bizarre repo name, you can't\n> necessarily switch between host:file syntax and git:// syntax by simple\n> cut and paste. But you really can't _anyway_, since there is no\n> guarantee that they are rooted at the same location, or have the same\n> view of the filesystem.\n\n.. but in practice it works fine, especially for something like kernel.org \nwhere it really *is* the same filesystem, just mirrored out.\n\nAlso, more importantly, I think the quoting is *stupid*. It adds pointless \ncode for absolutely zero gain. Are you going to unquote '/'? Or how about \n'~'?\n\nIt's much nicer to just not have the quoting issue at all. Repo names are \nnames. Straight up.\n\n> > Personally, I think it's a much better idea to just be git-specific. \n> \n> Then why in the world did you choose a specifier syntax that looks\n> _exactly_ like a URL?\n\n.. because it's a simple format, and it *works*. The same way INI config \nfiles are simple and *work*.\n\nAnd because I didn't think I'd have to care about people who like f*cking \naround with idiotic details, rather than just get something that is useful \nand works!\n\nIf you don't like the fact that git doesn't quote, just don't use the \nmagic characters. It's that easy. And if somebody quotes the '/', just \ntell him off for being an ass.\n\nBut git can and should do the *sane* thing.\n\n\t\t\tLinus\n"},{"id":"57733","messageId":"4728EE95.1020004@op5.se","threadId":"10294","inReplyTo":"20071031204729.GB13300@coredump.intra.peff.net","subject":"Re: remote#branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-31T21:07:33Z","receivedAt":"2007-10-31T21:07:33Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jeff King wrote:\n> On Wed, Oct 31, 2007 at 08:28:36AM -0700, Linus Torvalds wrote:\n> \n>> Because we don't care! This is *exactly* why I brought up the whole \n>> discussion about \"interoperability with a web browser\", and pointed out \n>> that there is no such thing *anyway*, since a GIT URL is generally not \n>> suitable for browsing _regardless_ of any encoding issues!\n>>\n>> So it doesn't matter one whit if a mail client recognizes GIT URL's or \n>> not! Because the mail client cannot do the right thing with them anyway, \n>> and would generally think that it's something that it should highlight so \n>> that you can browse it!\n> \n> Two points:\n> \n> 1. Just because _your_ mail client can't do anything useful with git\n> URLs^H^H^H^H repo specifications, doesn't mean that others can't.\n> \n> 2. You are conflating syntax and semantics. Think of the task I\n> mentioned as two subtasks: pulling the location specifier from the\n> email, and then doing something useful with it (in this case,\n> git-cloning it it). The first subtask depends _only_ on a parseable\n> syntax. The user can provide the context necessary for accomplishing\n> the second subtask.\n> \n> For example, consider a terminal that, upon pressing some keyboard\n> combination, will highlight the first URL-ish looking blob on the\n> screen, prompt you for a command, and then execute '$command $url'. The\n> terminal doesn't have to know the semantics of the blob, but it has to\n> know the syntax. The user provides the semantics.\n> \n> And yes, such a terminal exists, and I'm using it right now.\n> \n\nGreat. Now you just need a git-repo with an url that needs quoting, and\nthis discussion could at least potentially solve a real problem for someone.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57737","messageId":"2c6b72b30710311417i255df44eue7eb9d63ea9fcd9@mail.gmail.com","threadId":"10294","inReplyTo":"20071031170951.GR18279@machine.or.cz","subject":"Re: cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2007-10-31T21:17:10Z","receivedAt":"2007-10-31T21:17:10Z","isPatch":true,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On Oct 31, 2007 6:09 PM, Petr Baudis wrote:\n> And some command in Git to easily get the equivalent of cg-status -g\n> output is something I probably miss the most in Git now. (Originally I\n> was about to say that I just miss an equivalent of cg-status, but\n> thinking about it, most of the time I'm interested only in either -g\n> (long branch info) or -w (git status output)).\n\nTry `git branch -v` ... maybe with an added -a.\n\n-- \nJonas Fonseca\n"},{"id":"57740","messageId":"20071031212655.GB13823@coredump.intra.peff.net","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710311350100.3342@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-31T21:26:55Z","receivedAt":"2007-10-31T21:26:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 31, 2007 at 02:01:54PM -0700, Linus Torvalds wrote:\n\n> > Yes, this means that if you have a bizarre repo name, you can't\n> > necessarily switch between host:file syntax and git:// syntax by simple\n> > cut and paste. But you really can't _anyway_, since there is no\n> > guarantee that they are rooted at the same location, or have the same\n> > view of the filesystem.\n> \n> .. but in practice it works fine, especially for something like kernel.org \n> where it really *is* the same filesystem, just mirrored out.\n\nYes, and in practice, it works with or without URL encoding, since\npeople aren't using names that need encoded.\n\n> Also, more importantly, I think the quoting is *stupid*. It adds pointless \n> code for absolutely zero gain. Are you going to unquote '/'? Or how about \n> '~'?\n\nI don't think it's zero gain; I think it's exactly what users who use\nrepos with characters that need quoting will expect to happen. That\nbeing said, _I_ don't personally care that much since I think spaces in\nfilenames are the work of the devil, and I will never use them. And as a\nresult, I'm not going to implement the code to do it.\n\nBut I do think your argument that there is no value in the URL syntax is\njust wrong.\n\nI don't understand your mention of '~' and '/'; they don't need quoted\nin URLs, and generally are not (though of course they can be).\n\n> .. because it's a simple format, and it *works*. The same way INI config \n> files are simple and *work*.\n\nBut if you wrote a bunch of documentation referring to the git config\nfile as an INI file, would you expect people to complain when it\n_didn't_ follow the usual expectation for INI files?\n\n\nOK, this discussion is just getting nowhere, and there is useful git\nwork I could be doing, so let me sum up my position:\n\n - We should either resolve that some repo specifiers are URLs, or we\n should resolve that they are not. I think they are.\n - If they are URLs, then we should treat them like URLs, and not\n handling quoting is probably a bug. I refuse to accept that it is an\n _important_ bug until somebody actually has a repo that needs\n quoting, finds that git is substandard, and provides a patch.\n - If they are not URLs, then we should probably stop calling them that\n in the documentation.\n\nAnd with that, I shall say no more on the subject. In the spirit of not\nsaying \"oh, I don't want to talk about it anymore, you don't get to say\nanything else,\" I invite you to respond to any of my comments above.\n\n-Peff\n"},{"id":"57742","messageId":"alpine.LFD.0.999.0710311416450.3342@woody.linux-foundation.org","threadId":"10294","inReplyTo":"alpine.LFD.0.999.0710311350100.3342@woody.linux-foundation.org","subject":"Re: remote#branch","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-31T21:28:05Z","receivedAt":"2007-10-31T21:28:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 31 Oct 2007, Linus Torvalds wrote:\n> \n> If you don't like the fact that git doesn't quote, just don't use the \n> magic characters. It's that easy. And if somebody quotes the '/', just \n> tell him off for being an ass.\n\nSide note - none of the repos I use are likely to actually have any \nquoting as an issue, so in that sense I don't actually care. I'd never \nnotice if git did any quoting or not.\n\nWhat I care about - and where I entered the discussion - is that the real \nimpetus for this *stupid* quoting is not the actual need for quoting in \nitself (which doesn't seem to exist), but because people want to extend \nthe repository naming to contain other things too, in particular the \nbroken cogito single-branch naming thing.\n\nSo I could care less about some detail that I'll never even notice, if it \nwasn't for the fact that there's all this other baggage that goes with \nthis whole thing. So the quoting itself is more of a symptom of the real \nproblem.\n\nGuess what? I didn't make the config file follow any Windows INI standards \neither. I'm just waiting for the first person to point out that you cannot \nparse a .gitconfig file with standard INI parsers.\n\n\t\t\tLinus\n"},{"id":"57744","messageId":"20071031213101.GC13823@coredump.intra.peff.net","threadId":"10294","inReplyTo":"4728EE95.1020004@op5.se","subject":"Re: remote#branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-31T21:31:02Z","receivedAt":"2007-10-31T21:31:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 31, 2007 at 10:07:33PM +0100, Andreas Ericsson wrote:\n\n> Great. Now you just need a git-repo with an url that needs quoting, and\n> this discussion could at least potentially solve a real problem for someone.\n\nI would make one on repo.or.cz just to spite you, but it refuses to\ncreate repos with exotic characters in the name.\n\n-Peff\n\nP.S. I agree with your point.\n"},{"id":"57763","messageId":"200711010122.34190.jnareb@gmail.com","threadId":"10294","inReplyTo":"20071031091529.GA25025@glandium.org","subject":"Re: remote#branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-01T00:22:33Z","receivedAt":"2007-11-01T00:22:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Mike Hommey wrote:\n> On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson wrote:\n>>>\n>>>Or copied from gitweb.\n>>>\n>> Perhaps, but I've never seen that done. Partly because you can't be sure\n>> the HTTP url is the same as the git address (perhaps people are used to\n>> this from CVS and the likes), and partly because you'd, for most cases,\n>> want to use git:// or ssh transport instead of http.\n>> \n>> It might be nifty to have gitweb print some git-valid locator for a repo\n>> though, or even a full copy-pastable \"git clone git://host/path/to/repo.git\"\n>> command-line thingie. I'll look into it when I have leisure.\n> \n> Hum... it already does print http and git \"Mirror URL\"s which are ready to\n> be copy/pasted to feed git clone arguments.\n\nThe only thing to add (for absolutely no gain IMHO) would be code\nwhich would add quotes (single or double) around URL/path which\ncontain spaces:\n \n Mirror URL 'git://repo.or.cz/repo with spaces.git'\n 'http://repo.or.cz/r/repo with spaces.git'\n Push URL 'repo.or.cz:/srv/git/repo with spaces.git' \n\n-- \nJakub Narebski\nPoland\n"},{"id":"57780","messageId":"20071101051133.GA8847@thunk.org","threadId":"10294","inReplyTo":"200711010122.34190.jnareb@gmail.com","subject":"Re: remote#branch","fromName":"Theodore Tso","fromEmail":"tytso@thunk.org","sentAt":"2007-11-01T05:11:34Z","receivedAt":"2007-11-01T05:11:34Z","isPatch":false,"sender":{"key":"tytso@thunk.org","avatar":"https://gravatar.com/avatar/bc16cd364de8c963cca27953f33db8cd94de51b67922a7697620d8512a05ab01?d=mp&s=160"},"body":"On Thu, Nov 01, 2007 at 01:22:33AM +0100, Jakub Narebski wrote:\n> The only thing to add (for absolutely no gain IMHO) would be code\n> which would add quotes (single or double) around URL/path which\n> contain spaces:\n> \n> Mirror URL 'git://repo.or.cz/repo with spaces.git'\n> 'http://repo.or.cz/r/repo with spaces.git'\n> Push URL 'repo.or.cz:/srv/git/repo with spaces.git' \n\nThe one thing that I think might be worth doing out of all of this is\nto add code to git so that it can accept URL quoted arguments. Given\nthat it's highly unlikely anyone is using repository pathnames that\ncontain the '%' character, this would be highly unlikely to cause any\nbackwards compatibility problems.\n\n\t\t\t\t\t- Ted\n"},{"id":"57790","messageId":"47298070.4060500@op5.se","threadId":"10294","inReplyTo":"20071031091529.GA25025@glandium.org","subject":"Re: remote#branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-01T07:29:52Z","receivedAt":"2007-11-01T07:29:52Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Mike Hommey wrote:\n> On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson wrote:\n>>> Or copied from gitweb.\n>>>\n>> Perhaps, but I've never seen that done. Partly because you can't be sure\n>> the HTTP url is the same as the git address (perhaps people are used to\n>> this from CVS and the likes), and partly because you'd, for most cases,\n>> want to use git:// or ssh transport instead of http.\n>>\n>> It might be nifty to have gitweb print some git-valid locator for a repo\n>> though, or even a full copy-pastable \"git clone git://host/path/to/repo.git\"\n>> command-line thingie. I'll look into it when I have leisure.\n> \n> Hum... it already does print http and git \"Mirror URL\"s which are ready to\n> be copy/pasted to feed git clone arguments.\n> \n\nTrue that. I went looking for such an option a long time ago and didn't find\nit. I should do my research better.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"}]}