It sounds like a good idea to remove all the references to Cogito from the git homepage since it's not longer supported.

Changes tested with a local installation of the web server lighttpd
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>

---

 index.html |   12 +-----------

 1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/index.html b/index.html

index 340aee0..41605ed 100644

--- a/index.html

+++ b/index.html

@@ -94,7 +94,6 @@ Junio C Hamano.</p>

 	-->

 	<br /><a href="course/stgit.html">Maintaining external patches</a>

 	<br /><a href="course/svn.html">Git for SVN users</a>

-	<br /><a href="course/cvs.html">Cogito for CVS users</a>

 	<br /><em>More to come soon...</em>

 	</tr></td>

 </table></div>

@@ -286,15 +285,6 @@ a gitweb interface, at <a href="http://repo.or.cz/">http://repo.or.cz/</a>.</p>
 <dl>
-<dt id="cogito">Cogito</dt>

-<dd>

-<a href="http://git.or.cz/cogito/">Cogito</a>

-is a popular version control system on top of Git.

-It aims at seamless user interface and ease of use, providing

-generally smoother user experience than the "raw" Git interface

-and indeed also many other version control systems. However, it

-also lacks many advanced capabilities of Git and is currently

-being slowly phased out.</dd>
 <dt id="stgit">StGIT</dt>

 <dd><a href="http://www.procode.org/stgit/">Stacked Git</a> provides

@@ -340,7 +330,7 @@ with help of a group of hackers 'round the net.

 It is currently maintained by

 Junio C Hamano.</p>
-<p>The user discussion and development of Git, Cogito and other tools related to Git

+<p>The user discussion and development of Git and other tools related to Git

 takes place on the Git mailing list - everyone is welcome to post

 bug reports, feature requests, comments and patches to

 <a hre...
[ message continues ]

I'm not sure this is good idea, Cogito is still quite frequently used

and it should be documented that it exists.
--

				Petr "Pasky" Baudis

Early to rise and early to bed makes a male healthy and wealthy and dead.

                -- James Thurber

-

I think reformulating the mention to cogito (use past sentence like

"cogito was a popular ...") would be better. As a side-effect, it

would also credit you for your work, which I think is fair :-).
--

Matthieu

-

Yes, I probably be too rude. Sorry abot that Pasky, I just feel like

the home page is a bit confusing with regards to Cogito. My

understanding is that it is no longer maintained and therefore we

probably should not encourage new user to use it.
Maybe changing:

Cogito

    Cogito is a popular version control system on top of Git. It aims

at seamless user interface and ease of use, providing generally

smoother user experience than the "raw" Git interface and indeed also

many other version control systems. However, it also lacks many

advanced capabilities of Git and is currently being slowly phased out.
into

Cogito

    Cogito was a popular version control system on top of Git. It aims

at seamless user interface and ease of use, providing generally

smoother user experience than the "raw" Git interface and indeed also

many other version control systems. However, it also lacks many

advanced capabilities of Git and is not actively maintained any

longer.
Ciao,

--

Paolo

http://paolo.ciarrocchi.googlepages.com/

-

Hi, I've been using git for a month now and loving it. This is my

first ever patch for git using git. I spent sometime to find out why

the project listing is taking 200s, everytime! I guess that gitweb is

mostly used to serve bare repositories, which would never encounter

such problems. It takes .2s, after the patch on my laptop. That's

1000x improvement for me (on Mac OS X 1.4.10.)
__Luke
Signed-off-by: Luke Lu <git@vicaya.com>

---

gitweb/gitweb.perl |    4 ++++

1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl

index 3064298..a30eef9 100755

--- a/gitweb/gitweb.perl

+++ b/gitweb/gitweb.perl

@@ -1509,16 +1509,20 @@ sub git_get_projects_list {

		# remove the trailing "/"

		$dir =~ s!/+$!!;

		my $pfxlen = length("$dir");

+		my $pfxdepth = ($dir =~ tr!/!!);

		File::Find::find({

			follow_fast => 1, # follow symbolic links

			follow_skip => 2, # ignore duplicates

+			no_chdir => 1, # don't chdir into every directory

			dangling_symlinks => 0, # ignore dangling symlinks, silently

			wanted => sub {

				# skip project-list toplevel, if we get it.

				return if (m!^[/.]$!);

				# only directories can be git repositories

				return unless (-d $_);

+				# don't traverse too deep (Find is super slow on os x)

+				return if tr!/!! - $pfxdepth > 2 && ($File::Find::prune = 1);

				my $subdir = substr($File::Find::name, $pfxlen + 1);

				# we check related file in $projectroot

--

1.5.3.4
-

It shows. The patch is whitespace damaged, and the commit message leaves

a little something to desire. I suggest you read through

Documentation/SubmittingPatches and then re-send your patch. Try sending

to yourself and looking at the result with a monospace font. It's what I

always do to make sure patches look okay before sending them to the list.
Not trying to be rude or anything. Oldtime list-members sometimes get to

hear the exact same thing.
Also, Junio, the maintainer, is currently away, so don't worry if your

patches are left in limbo for some time. Someone will pick it up and

carry it forward for Junio to pull, or he'll hack up some script to

get all patces from his mailbox and review them one by one. He's a very
Sweet job :)
I'll have to test this, as we've got a few repos at work with a checked out

working tree connected to the repos. I haven't run into your issues though,

but perhaps that's because we run it under Linux.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hi,
  that'd be sweet to have but this is unfortunately not so simple; this

change would e.g. break gitweb on repo.or.cz, where some projects can

live quite deep inside the tree due to forks.
  I guess the best way would be to introduce a configuration option that

lets you potentially limit the $pfxdepth, but does not force the limit.
--

				Petr "Pasky" Baudis

Early to rise and early to bed makes a male healthy and wealthy and dead.

                -- James Thurber

-

Hi,
I agree.  But maybe it could be marked as unmaintained?  Maybe someone

steps up to maintain it.  Or, even better, comes up with a list of "this

is what I like do regularly with cogito, but there's no easy way with core

git" issues.
In related news, I recently thought about the url#branch issue.
There were three arguments against it AFAIR: "#" is a comment marker, and

this syntax is not extensible to more than one branch names.  And that the

branch name is not really a part of the URL.
Turns out that I am not so sure about the last two issues.
It is easily extensible to more than one branch by remote#branch1#branch2,

and in a very real sense, this is a resource locator.
And we could replace the "#" by every character that is illegal in ref

names as well as URLs.  I propose SPC.  ('#' is allowed in refnames.)
Ciao,

Dscho
-

One thing that I occasionally miss is
  cg-export /path/to/directory/
And yes, I know it can be accomplished via "obscurities" like

git-archive+tar (or worse git-checkout-index) but I think having

an easy way to checkout to a directory could be great (and possibly

with the ability to apply substitutions with the recent discussion).
Else, I am really looking forward for the option parser work to provide

an easy way to list options. I found it very useful with Cogito.

Also, most of the "status" commands in Cogito seemd to provide a richer

default output geared towards human consumption. For example stuff like

git-branch -v and git remote -v flags would have been the default for

Cogito ... I think.
--

Jonas Fonseca

-

A "me too" mail for once...
I fully second this. cg-export is one of the Cogito commands I still use

frequently. I wonder if there is any obvious piece of Git command set we

could glue this on (so that we don't introduce Yet Another Command)... I

think cg-export is better-named here than git-archive. ;-)
And some command in Git to easily get the equivalent of cg-status -g

output is something I probably miss the most in Git now. (Originally I

was about to say that I just miss an equivalent of cg-status, but

thinking about it, most of the time I'm interested only in either -g

(long branch info) or -w (git status output)).
--

				Petr "Pasky" Baudis

We don't know who it was that discovered water, but we're pretty sure

that it wasn't a fish.		-- Marshall McLuhan

-

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

Jonas Fonseca

-

It's a question, whether the branch name is part of the URI, or a fragment.
Current usage suggests it is a fragment, but according to the URL

specification that is supposed to mean that the resource is always accessed

the same (fragment is NOT part of the URL) and the fragment only affects

local handling. Which I don't think is really true.
If it is a fragment, than "#" is the only correct separator and should stay

that way.
If it is not a true fragment, than we might want to phase it out in favor of

something else. But I would strongly prefer staying within characters allow=

ed

in URI (as per rfc2396). We could consider whether the branch is not

a component parameter -- which would imply ";" as separator, but I would vo=

te

against that on the basis that it's shell special. Non-special characters

allowed by URL in this context would be ":", "@", "=3D", "+", and ",", of w=

hich

":" or "@" seem best to me.
As for multiple branches, separating them with "," feels logical to me, no

matter what separates them from the repository path. On the other hand given

that neither ":" nor "@" is allowed in refnames, reusing the same separator

would make sense especially if git switched to either of those.
--=20

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

Hi,
You did not listen, did you?  '#' is allowed in ref names.  Therefore this

character really would lock us in to only ever reference _one_ and _only_

one remote branch at a time.  This might have worked for cogito, but it

does not for git.
If you do that, "http://<xyz-with-branch>" would be ambiguous, wouldn't

it?  This would already reference an HTTP resource, and you could not 
',' is allowed in ref names, so ',' is out.
Ciao,

Dscho
-

Actually since many characters that are allowed in ref name are not allowed

in URL at all, the ref-name has to be url-escaped. Which brings all

characters back in, because they can always be specified escaped.
--=20

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

Hi,
No.  The URL part of it has to be encoded.  But the ref names do _not_.

(If we really want to have a way to specify the remote URL and the

branch(es) we want to fetch _at the same time_.)
Ciao,

Dscho
-

If the branch names are not url-escaped, than the result is not an URL. Whi=

ch

is just ugly and confusing. If it looks like an URL, it should better be on=

e.
--=20

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

Hi,
So all you're saying is: it is not possible.
Well, discussion ended, I guess.
Ciao,

Dscho
-

Git remote names already aren't "url"s in the http sense. 
We say "master:some.host/file/goes here/without/any/stupid/web-escapes"

for the ssh names, and the same goes for "file:///name here" etc.
People who think that git URL's are web-pages had better wake up and smell

the coffee. They aren't. They never were. They never *should* be.
This whole argument is idiotic. The #branch format was a mistake of

cogito. Cogito is dead. Get over it already.
We have a format already, and it has nothing to do with '#' or any idiotic

web escape, or anything else.
			Linus

-

Well, the confusion is that we refer to things that look like

"git://git.kernel.org/pub/scm/git/git.git" as if it were a URL.  In

fact, you did so yourself in the last paragraph above.  "People who

think that git URL's"....  but in fact, whether or not Universal

Resource Locators (URL's) in the RFC 3986 sense requires quoting

doesn't matter whether or not they are web pages or not.  If they are

formal URL's in the sense of RFC 3986, it doesn't matter whether they

are http URL's, or ldap URL's, or telephone URL's, etc. they are

supposed to be quoted whether or not they appear in a web form or not.

The whole point of URL's is that they are *uniform*.
So what that means is the much more correct statement is:
"People who think the names that people specify that to git, which

sometimes include names that look very much like URL's, especially

when they begin 'git://' or 'http://', and they think they are really

RFC 3986 URL's had better wake up and smell the coffee.  They aren't.

They never were.  The they never *should* be.  
The best that we can say given existing usage is that what git accepts

is a superset of what is allowable by RFC 3986 syntactically, and that

git in general doesn't do any URL-style quoting, even when given a

name that looks syntactically like a http-style URL that begins

'http://'."
What this means in practice though is that people would be well

advised not to pick locator names (NOT URL's) that contain characters

that normally would require escaping by RFC 3986 rules, since the

inconsistency of whether tools that expect URL-style quoting rules

will probably cause user and tools confusion.  Hence, it would

probably be a bad idea to place a directory pathname that included the

'#' character on a web server and expect that resulting git:// and

http:// names generated by an Apache web server and gitweb scripts to

do sane things, not to mention direct access via git:// names used

when you do a "git push" to said respository.  Sometimes the name will

require R...
[ message continues ]

Sure, but "URL" in human-speak has nothing to do with an RFC.
I dislike language-lawyerese. Why the hell do people think that human

language should follow the RFC's?
Git addresses look like URL's, and they act like URL's, but dammit, git

isn't a web browser, and it's not interested in acting like one. 
And "standards" are only as good as they are useful. XML is a piece of

crap despite being a standard because it makes no sense. Similarly, "URL

quoting" is a piece of crap when _it_ makes no sense. Having a RFC or an

ISO standard doesn't change anything, and doesn't imply that human

communication (or indeed, even machine communication) should care.
			Linus

-

Hi,
To be fair, there are uses for XML.  On Halloween, for example.
Sorry, could not resist,

Dscho
-

The quoting rules aren't specific to a web browser; the whole point of

URL's is that they are uniform so that programs know how to handle

them without needing information specific to the URL type.  Hence the

quoting rules apply to all applications using URL's, whether it's CUPS

using a url such as: ipp://example.com/printer/tiger/bob or LDAP using

a url such as: ldap://ldap.example.com/dc=example,dc=com?postalAddress.
It's just git which is different here.  Having a uniform set of

processing rules are *useful* for applications and libraries that are

parsing URL's, not just for language-lawyer wanking.  Not that git

addresses that are layered on top of http is all that well supported

any more, but in that case we really are using an http-style URL ---

but yet git doesn't do URL quoting, because, well, it doesn't.  Yet in

that case it's very clear the http address is really a URL, and it's

arguably a defect that git doesn't handle an http address the way all

other applications handle http URL's.
At the very least, if we aren't going to change git, we should hang a

big fat sign in the documentation saying that although git location

names that begin git:// look like URL's, and smell like URL's, they

aren't treated the same way that all other applications treat URL's,

and the user shouldn't be surprised by this.  Furthermore, choosing

pathnames so that git:// and gitweb http:// addresses don't require

URL-style quoting, will probably save the user a fair amount of pain

and confusion because git refuses to treat git addresses as URL's.
It would probably also be a good idea to expurgate URL's from the

documentations, because, well, they aren't URL's.  Git doesn't treat

them like URL's, and you've said you aren't interested in changing git

to treat them like URL's, and finally git:// isn't a registered URL

scheme name with the IANA registration authority.  So let's not call

them URL's, since they're clearly not.
    	      	      	  	     - Ted

-

Hey, you go ahead.
Me, I'll refuse to make up a new name just because somebody thinks they

"own" the concept of URL's.
Let's face it, nobody really cares.
		Linus

-

Are you playing reverse psychology, encouraging us to switch to

RFC-conforming quoting?
-

Well, URL's have a specific meaning and they're not for web browsing.

They are used to specify the addresses of printers, e-mail addresses,

LDAP servers, and much more.  Git is using something that looks like

URL's, but they they don't follow the URL rules.  So this brings up

interesting questions when a git webpage displayes something like

this (taken from repo.or.cz):
Mirror URL  git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git

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

Push URL    git+ssh://repo.or.cz/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
Quick!  Which of the URL-like strings follow the URL quoting rules,

and which ones don't?  And if you have a character that must be quoted

in the pthname, should be quoted in in the http:// line?  And does it

matter if you are passing that URL-like string to a web browser or to

git-clone?
This is not language lawyering; this is a consistency issue that

matters.  But if Linus is going to say that git isn't going to follow

the URL quoting rules because it isn't a web browser, then clearly

what we are using aren't URL's.  So let's not *call* them URL's in our

documentation, because we're not following the URL rules.  That way is

only going to spawn more confusion.
Is this reverse psychology?  Well, I think git needs to pick whether

we operate on URL's or just things that *look* like URL's.  Either

way, the documentation should be specific about what's going on.  Me,

I'd prefer that git be liberal in what it accepts, and conservative in

what it sends.  That means that it would be useful if git could accept

URL's that are correctly quoted, and let things slide if characters

that should be quoted, aren't.  Git rarely actually emits URL's, and

mercifully people rarely use things like '#' characters in their

pathnames, so I don't think it would be that hard to make the

transition.
     	 	       	      	 	  - Ted

-

No.
The push url is generally written as
	repo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
Quick! WHO THE F*CK CARES?
		Linus

-

Ah, damn. In all the discussion & flamefesting to say that people

don't want to use the # character, noone talks about of what cogito

used it for.
Having something functionally similar to
  cg-clone git://foo.tld/bar.git#blue
would save a few steps -- and some potential confusion -- for projects

using GIT.
In case it's not clear what it does (not everyone here has used

cogito) it will create and checkout a branch tracking the "blue" head

on the repo when the clone is done. This is _instead of_ creating and

checking out the branch that tracks the configured "HEAD" of the repo.
IMHO is a quite nice thing to have -- and AFAICS we don't have it in

master or pu. I care about the shed for the bike, not its colour.

cheers,
m

-

Actually, IIRC it won't fetch any of the non 'blue' refs.
Anyway, to recap (my impression of) the discussion leading up to this:

  - the cogito feature is useful

  - the cogito syntax does not allow for multiple branches to be

    specified

  - one such syntax proposed was git://foo.tld/bar.git#blue,red

  - one problem with that syntax is that comma is a valid character

    in the branch name, and '#' is a valid character in the repo name

  - one proposed solution was that '#' and ',' when used as data should

    be URL-encoded

  - flamefest begin
So I think nobody disagrees that such a feature is useful; there is

disagreement about the syntax.
-Peff

-

Hi,
Here somebody else than me (IIRC Junio) proposed this syntax:
	git clone --track <name> [--track <name2>] <url>
Nobody was interested enough to implement it.
I then proposed delimiting with spaces, since they were _not part of a

URL_:
	git clone "<url> <name> <name2>"
but some people insisted on "#", which I pointed out (several times!) is a 
Probably there is not enough need, too, and the discussion will peter out

again, without anybody letting some code talk, and I will not make the

mistake again of reviving this discussion.  Promise.
Ciao,

Dscho
-

You recall correctly, and that was a cogito misfeature. I don't think
Great summary. I read the first and last stages you describe (with a

trip in the middle distracting me). Heh.
No stress. Let the flames continue!
m

-

I'm not so sure. Junio keeps unrelated branches in git.git like 'html'

and 'todo'. Is it unreasonable to say "clone git.git, but only the todo

branch" and expect it _not_ to download the entire git history?
-Peff

-

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

syntax.
The thing is, we don't want a single branch name. Not for clone, not for

fetch, not for pull, and not for push.
Yes, a single branch may be one common case, but it's definitely not the

only one, and it's fundamentally the wrong thing to use as a definition of

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

-

Hi,
I second this.
Should we -- ever -- encounter problems with the way we do things, we can

still fix it.  So far, our "inconsistent" behaviour has not given me

grief.
Ciao,

Dscho
-

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

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

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

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

http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
Note: this doesn't have anything to do with server:/path/to/repo
Not that I care, but git should probably handle things consistently.
  Tom
-

Yes, for anonymous pulling.
The thing is, git takes something much more extended than a "RFC url".
We use pathnames. Not a "quoted mess". Regular, bog-standard, normal unix

pathnames.
On Windows, I assume (and hope) that git uses the native-style Windows

pathnames, and you can do "git pull d:\system\ugh" if you want to.
And I think we should care a whole lot about interacting with the *user*

and actual programs that git shares code with, than interacting with some

idiotic RFC that has absolutely zero to do with us, regardless of whether

we use the name "url" or not.
For example, the reason we use "host:/path" for pushing over ssh (and

pulling, for that matter), is that that's the same syntax that scp uses.

It's a natural fit. And I hope to God nobody seriously argues that we 
[ Btw, sorry for the french. I blame being tired and ina bad mood, but I

  also blame the fact that I absolutely *detest* arguments based on

  standards. If you cannot back it up with a real usage scenario, you 
The way it has always cared. Git itself does no quoting what-so-ever

(except for the *argument* quoting etc that it needs).
Now, the *transport* back-end may end up quoting it, of course, the same

way it may end up using some random protocol. The user shouldn't care

about the implementation details!
In the case of the git transport, there is no quoting even by the

transport protocol. In the case of http, libcurl would hopefully quote for 
No difference, what-so-ever, that I can see. Git doesn't quote it.
Notice how the fact that we use http:// doesn't actually mean that you can

feed the result to a web browser anyway? It's not like you get a "link"

that git follows. You get a name.
Yes, you can try to "co-locate" things so that something smart

disambiguates (maybe have an "index.html" file, so a web browser gets a

gitweb page, and git gets the raw data). But even then, notice how even

web browser will do the quoting for you: try
	firefox "http://www.goog...
[ message continues ]

Yes. But the server will unquote it. ' ' should not have been there, but it=

's

just passed through if it was. '+' is quoting for ' ' and '%20' is quoting

for ' ' as well. Therefore all these three addresses are the *SAME*.
Now the user expectation will be that when these are the same, the git://

ones above will be as well. But they are not. This is not about following a=

ny
The first three don't look like URL ("URL" always means the thing defined by

RFC 2396, at least to me), so I don't expect any quoting there. But for the

last case http:// (and for that matter, sftp://) do use quoting, so I would

expect the quoting of something that differs only by starting with git:// to

work the same.=20
--=20

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

I don't think the
  '+' is quoting for ' '
part is fully correct, at least not if you're talking about

"real RFC 2396 URLs" (not "Git URLs").  I might misunderstand

you here, but there has also been other postings suggesting

that plus should/could be used instead of space, implying that

people think that pluses are always transformed to spaces in

URLs.  But if I understand RFC 2396 correctly, this is *not*

the case.
RFC 2396 says that pluses are treated as "reserved" in the

*query* part of the URL (ie on the right side of the question

mark) -- here they *are* transformed to spaces, although the

RFC itself doesn't really say specifically what happens to

them.  In the path part, pluses are not "reserved", they are

simply a "pchar" along with "unreserved", "escaped" and a

couple of other characters.  There is nothing in the RFC

implying that pluses in the path part will be transformed into

spaces, and in my experience this does not happen in practice

either.
To recap:
  (In the examples below <...> is used to mean legal URLs,

  while "..." is used to mean "the literal characters in the

  URL" (more or less))
  * In the query part:
      '%20' = '+' = a literal space

      '%2B' =       a literal plus
    For example:
        <http://example.com/somescript?v=x%20y>

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

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

      = "http://example.com/somescript?v=x+y"
  * In the path part:
      '%20' =       a literal space

      '%2B' = '+' = a literal plus
    For example:
        <http://example.com/x%20y.html>

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

      = <http://example.com/x+y>

      = "http://example.com/x+y"
I'm not advocating that "Git URLs" necessarily should be made

fully RFC 2396 compliant (neither am I nitpicking just for the

sake of nitpicking), I'm just pointing out that...
[ message continues ]

Ok, you have some reading comprehension skills.
Read the above again.
I'd certainly hope that *curl* does the proper quoting. That's a transport

issue.
		Linus

-

Well, only the last one actually looks like a URL, so that is the only this

discussion is about. I don't think anyone is suggesting that the first three

be changed at all. So, to use your terminology, git has a variety of ways to

specify a repo name, one of which happens to be a URL (or looks like one). The

suggestion is that we should make that way (and only that way) behave like a

RFC URL.
And git should be consistent with web browsers, automatically quoting things

it gets passed. I think the only point of contention is probably how to deal

with URLs that git receives that are already quoted.
1. We ignore the quoting and re-encode everything for the http transport.

2. We honour the encoding and decode everything for the git transport.

3. We handle git:// and http:// different, so that the three git:// URLs below

refer to different repositories, while the three http:// URLs give refer to
The third possibility is probably what we do now, which is why I am suggesting

git is inconsistent. The first will fall down when using a repository that is

colocated, and somebody copies a URL from the web browsers location bar (which

will be properly encoded). Which leaves the second.
  Tom
-

NO.
The thing is, we'd be much better off being consistent with OURSELVES than

with something else!
Nobody cares about git being consistent with a web browser. There is

nothing in common.
But I *do* care about git being consistent with itself. If I do
	git clone /some/directory
and then decide that I want to generate a new pack and change it into
	git clone file:///some/directory
I don't want to have to re-write the thing to quote differently!
The same very much goes for a path like
	git://git.kernel.org/<path>
vs
	master.kernel.org:<path>
because I will use the two interchangably. They *are* the same address,

except:
 - the "git://" protocol is a bit faster, since the ssh connection

   overhead is actually big enough to be quite noticeable.
 - but I often use the master.kernel.org:<path> thing because there's a

   mirroring delay that means that accessing it directly is sometimes

   preferable.
See? THAT is where we need to be consistent: with our own paths!
[ And yes, I literally really do switch things around exactly like that

  between ssh accesses and the git:// protocol. That was not a made-up

  example, but real usage! ]
In contrast, nobody has _ever_ given a real technical reason to care about

the Web URL RFC at all.
Really. It's that simple: if you cannot argue for something without

pointing to an irrelevant standard, you really shouldn't argue for it in

the first place.
People who make decisions based on "it's a standard" make *sub*standard

decisions. The fact is, most standards are not worth even using as toilet

paper, because they were designed by some committee that wanted to reach

"consensus". That's just crap.
                        Linus

-

Why do you keep talking about web browser?
URLs are _not_ a web-browser thing. A web browser is just _one_

example of program which uses URLs.
--

Matthieu

-

I keep talking about a web browser, because THE ONLY POINT of following a

standard is to interoperate.
So if you cannot find something to interoperate with, why the hell would

you care about the standard?
So here's a question: why do people bother to quote irrelevant RFC's?
Following those RFC's would make git not interoperate WITH ITSELF, and use

illogically different formats for the same things.
So if you want to make that RFC have any relevance what-so-ever, then show

some interoperability issue. Which is why I'm bringing up a web browser:

that interop issue simply *does*not*exist*.
Why is that so hard to understand?
			Linus

-

Btw, the reason I care is that the whole ".. but it's a standard" thinking

really is dangerous. It's how you create absolute and utter crap.
It's why I have also brought up XML in this discussion, because XML is a

classic example of something where this ".. but it's a standard" thinking

has resulted in really bad solutions. It's pushed as a way to

"interoperate", but then, since everybody does different things, the only

thing you can actually interoperate with is by having a common parsing

library for a REALLY HORRIBLY BAD FORMAT!
The same is true of a URL. What is there to interoperate with? The whole

(and only) point of the git remote URL is to point git to a different git

repository. There's no other reason to use it. So the only possible case

we care about interoperability is with other git uses.
And those other git uses are not RFC1738-quoted, are they? 
			Linus

-

Yes, and since URLs are not used for web browser only I do not see the
I'm thinking alike :)
Pascal;
-- 
--|------------------------------------------------------

--| Pascal Obry                           Team-Ada Member

--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE

--|------------------------------------------------------

--|              http://www.obry.net

--| "The best way to travel is by means of imagination"

--|

--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
-

Hey, it's find if you can come up with some *other* case why we should

care about RFC 1738.
I certainly didn't mean to bring up browsers as the _only_ case of

possible interoperability issues, but when it comes to URL's it's

certainly the obvious one...
So the only argument really is:
 - Nobody has pointed to *any* reason to follow 1738.
 - I have pointed to reasons *not* to do it.
So if you want to follow the RFC, you'd better give a real reason. And no,

the existence of an RFC, and the fact that people use the same name for

things that superficially _look_ the same is not a reason in itself.
So hands up, people. Anybody who asked for RFC quoting. Give a damn

*reason* already!
			Linus

-

I didn't ask for RFC quoting, but a nice side effect of URL syntax is

that they are machine parseable. If you wanted to write a tool to pick

the URLs out of this email and clone them as git repos, then how do you

find the end of:
  http://host/git repo with spaces in the path
compared to:
  http://host/git+repo+with+spaces+in+the+path
I don't know if that's worth changing anything in git (in fact, I'm not

even clear on _what_ people want to change; the point of this discussion

seems to be to argue about terminology). But you did ask for any reason

for quoting URLs.
-Peff

-

Just pedantic side-note: these two URLs are not equivalent. '+' is valid

substitute for a space only in query string part of URL. In path you

have to use %20.
--

				Petr "Pasky" Baudis

We don't know who it was that discovered water, but we're pretty sure

that it wasn't a fish.		-- Marshall McLuhan

-

You just write <URL:http://host/git repo with spaces in the path> and

have a good chance it will work.
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

Well "good chance" is not an option for reliable software :)
Pascal.
-- 
--|------------------------------------------------------

--| Pascal Obry                           Team-Ada Member

--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE

--|------------------------------------------------------

--|              http://www.obry.net

--| "The best way to travel is by means of imagination"

--|

--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
-

It doesn't with KMail.
-- robin

-

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

a URL:
http://host/git+repo+with+spaces+in+the+path
Both of these are incorrectly highlighted:
http://host/git repo with spaces in the path

<URL:http://host/git repo with spaces in the path>
And this one too:
<http://host/git repo with spaces in the path>
So what does this mean in practice? I can right-click on the first one

and choose "Copy". All the other ones I have to left-click and drag,

being careful to limit the selection to the appropriate left and right

boundaries.
Whether or not this is a big enough deal to actually care about is

open to debate (obviously). Personally, I don't care too much seeing

as I never use paths with spaces in them for this kind of thing.
Cheers,

Wincent
-

>>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:
Linus> So the only argument really is:
Linus>  - Nobody has pointed to *any* reason to follow 1738.
Linus>  - I have pointed to reasons *not* to do it.
I can support non-compliance with 1738.  However, I'd also suggest

that outside of this cozy group of developers, URL already has a heavily

defined meaning associated with 1738.
Therefore, I propose that the git docs refrain from calling these things

"URLs" because they're not, and instead adopt something like "GRL" (git

resources locator) or whatever.
--

Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095

<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>

Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

-

And what do you do with the remote.<name>.url config option?

Add some backward compatibility cruft for some... well... issue that

turns out not to be one in practice?
Again, can someone point to a real usage scenario where all this

discussion is solving something?
Nicolas

-

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

enough. But maybe not.
I think it's stupid to make up a new name, it's not like it's really

ambiguous *or* as if people really think in terms of RFC's.
Let's face it: people talk and use email, even when they don't have a clue

about SMTP. And in practice, you'll never see any difference, apart from

the obvious extension of using the ssh format and the direct local path

thing.
		Linus

-

I don't understand why you keep talking about web browser. URL is not a

web browser thing. It is the case that web browser are using URL, but

that's just one usage.
Pascal.
-- 
--|------------------------------------------------------

--| Pascal Obry                           Team-Ada Member

--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE

--|------------------------------------------------------

--|              http://www.obry.net

--| "The best way to travel is by means of imagination"

--|

--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
-