patchGit homepage: remove all the references to Cogito

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(-)

On Mon, Oct 15, 2007 at 11:38:00PM +0200, Paolo Ciarrocchi wrote:

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

Petr Baudis <pasky@suse.cz> writes:

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

On 10/16/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

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,

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(-)

Luke Lu wrote:

Hello Luke, and welcome to the community :)

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

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

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

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.

  Hi,

On Tue, Oct 16, 2007 at 02:04:14AM -0700, Luke Lu wrote:

  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.

Hi,

On Tue, 16 Oct 2007, Petr Baudis wrote:

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

On Tue, Oct 16, 2007 at 11:49:58 +0100, Johannes Schindelin wrote:

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

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

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

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

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

Hi,

On Tue, 16 Oct 2007, Jan Hudec wrote:

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

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

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

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

Ciao, Dscho

On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:

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

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

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.

Hi,

On Sat, 27 Oct 2007, Jan Hudec wrote:

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

On Sun, Oct 28, 2007 at 00:01:57 +0100, Johannes Schindelin wrote:

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

On Mon, 29 Oct 2007, Jan Hudec wrote:

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

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

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

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

On Mon, Oct 29, 2007 at 11:17:12AM -0700, Linus Torvalds wrote:

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

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

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

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

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

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

							- Ted

On Mon, 29 Oct 2007, Theodore Tso wrote:

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

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

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

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,

On Mon, 29 Oct 2007, Linus Torvalds wrote:

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

Sorry, could not resist, Dscho

On Mon, Oct 29, 2007 at 03:57:41PM -0700, Linus Torvalds wrote:

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

Theodore Tso <tytso@mit.edu> writes:

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

On Mon, Oct 29, 2007 at 08:40:06PM -0700, Junio C Hamano wrote:

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

On Tue, 30 Oct 2007, Theodore Tso wrote:

No.

The push url is generally written as

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

Tough.

Quick! WHO THE F*CK CARES?

		Linus

On Mon, Oct 29, 2007 at 09:51:47PM -0700, Linus Torvalds wrote:

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

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

On Tue, 30 Oct 2007, Tom Prince wrote:

Yes, for anonymous pulling.

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

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

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

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

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

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

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

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

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

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

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

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

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

just for fun.

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

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

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

 - 

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

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

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

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

			Linus

On Tue, Oct 30, 2007 at 07:59:45AM -0700, Linus Torvalds wrote:

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

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

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

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

On Tue, 30 Oct 2007, Tom Prince wrote:

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

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

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.

On Tue, 30 Oct 2007, Matthieu Moy wrote:

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

On Tue, 30 Oct 2007, Linus Torvalds wrote:

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

Linus Torvalds a écrit :

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

I'm thinking alike :)

Pascal;

On Tue, 30 Oct 2007, Pascal Obry wrote:

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

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.

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

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

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

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

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

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

Jeff King wrote:

You use

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

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

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

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

-Peff

Jeff King wrote:

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

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

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

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

rather than:

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

?

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

-Peff

Jeff King wrote:

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

On Wed, Oct 31, 2007 at 08:09:01AM +0100, Andreas Ericsson <ae@op5.se> wrote:

Or copied from gitweb.

Mike

Mike Hommey wrote:

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

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

On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson <ae@op5.se> wrote:

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

Mike

Mike Hommey wrote:

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

On Thu, Nov 01, 2007 at 01:22:33AM +0100, Jakub Narebski wrote:

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

					- Ted

Mike Hommey wrote:

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

Jeff King a écrit :

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

Pascal.

Jakub Narebski <jnareb@gmail.com> writes:

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

On Wed, 31 Oct 2007, David Kastrup wrote:

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

Why?

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

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

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

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

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

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

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

So to summarise:

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

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

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

			Linus

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

Two points:

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

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

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

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

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

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

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

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

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

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

-Peff

On Wed, 31 Oct 2007, Jeff King wrote:

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

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

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

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

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

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

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

			Linus

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

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

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

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

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

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

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

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

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

-Peff

On Wed, 31 Oct 2007, Linus Torvalds wrote:

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

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

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

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

			Linus

Jeff King wrote:

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

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

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

-Peff

P.S. I agree with your point.

Jeff King <peff@peff.net> writes:

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

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

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

onsdag 31 oktober 2007 skrev David Kastrup:

It doesn't with KMail.

-- robin

David Kastrup a écrit :

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

Pascal.

On Tue, Oct 30, 2007 at 07:58:23PM -0400, Jeff King wrote:

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.

Linus Torvalds a écrit :

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.

On Tue, Oct 30, 2007 at 07:59:45 -0700, Linus Torvalds wrote:

So the three addresses will all be different, right?

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

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

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

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.

On Tue, 30 Oct 2007, Jan Hudec wrote:

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

* Jan Hudec <bulb@ucw.cz> [2007-10-30 20:36:10 +0100]:

I don't think the

  '+' is quoting for ' '

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

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

To recap:

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

  * In the query part:

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

    For example:

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

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

  * In the path part:

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

    For example:

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

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

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

Hi,

On Mon, 29 Oct 2007, Linus Torvalds wrote:

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

On 10/30/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

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

On Wed, 31 Oct 2007, Martin Langhoff wrote:

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

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

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

On 10/31/07, Jeff King <peff@peff.net> wrote:

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

...

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

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

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

Hi,

On Tue, 30 Oct 2007, Jeff King wrote:

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

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

Nobody was interested enough to implement it.

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

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

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

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

On Mon, 29 Oct 2007, Theodore Tso wrote:

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

Hi,

On Mon, 29 Oct 2007, Jan Hudec wrote:

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

Well, discussion ended, I guess.

Ciao, Dscho

On 10/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

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.

On Wed, Oct 17, 2007 at 12:16:25AM +0200, Jonas Fonseca wrote:

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

On Oct 31, 2007 6:09 PM, Petr Baudis <pasky@suse.cz> wrote:

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