{"thread":{"id":"9666","subject":"repo.or.cz wishes?","startedAt":"2007-08-26T23:59:44Z","lastAt":"2007-09-01T02:58:57Z","messageCount":28,"participants":["Petr Baudis","Sven Verdoolaege","Sam Vilain","Johannes Schindelin","Linus Torvalds","Junio C Hamano","Matthieu Moy","Uwe Kleine-König","Martin Mares","Jakub Narebski","Jing Xue","Theodore Tso","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51616","messageId":"20070826235944.GM1219@pasky.or.cz","threadId":"9666","inReplyTo":null,"subject":"repo.or.cz wishes?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-26T23:59:44Z","receivedAt":"2007-08-26T23:59:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\n I've just finally killed the HTTP auth for project administration that\nwas destroying everyone's lives, and added support for resetting\nforgotten passwords, two main things that seemed to be the popular nits\nof the repo.or.cz audience.\n\n So now I wonder, what is the thing you miss most there? Any cool stuff\nrepo.or.cz could (preferrably easily) do and doesn't?\n\n And please don't ask for smaller roundtrip times of requests for\nadministrator assistance. ;-)\n\n Thanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"51618","messageId":"20070827001634.GB1976MdfPADPa@greensroom.kotnet.org","threadId":"9666","inReplyTo":"20070826235944.GM1219@pasky.or.cz","subject":"Re: repo.or.cz wishes?","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-08-27T00:16:34Z","receivedAt":"2007-08-27T00:16:34Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Mon, Aug 27, 2007 at 01:59:44AM +0200, Petr Baudis wrote:\n> So now I wonder, what is the thing you miss most there? Any cool stuff\n> repo.or.cz could (preferrably easily) do and doesn't?\n\nJust a minor nit, but how about dropping the \"git+\" from the\nPush URL?\n\nJakub was also talking about support in gitweb for specifying\nthe location of submodules. It would be nice if admins could\nset this information, wherever it ends up getting stored.\n\nskimo\n"},{"id":"51621","messageId":"20070827004153.GN1219@pasky.or.cz","threadId":"9666","inReplyTo":"20070827001634.GB1976MdfPADPa@greensroom.kotnet.org","subject":"Re: repo.or.cz wishes?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-27T00:41:53Z","receivedAt":"2007-08-27T00:41:53Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Aug 27, 2007 at 02:16:34AM CEST, Sven Verdoolaege wrote:\n> On Mon, Aug 27, 2007 at 01:59:44AM +0200, Petr Baudis wrote:\n> > So now I wonder, what is the thing you miss most there? Any cool stuff\n> > repo.or.cz could (preferrably easily) do and doesn't?\n> \n> Just a minor nit, but how about dropping the \"git+\" from the\n> Push URL?\n\nI'm a major proponent of the \"git+\" - it's just the correct thing to\nspecify. ssh:// by itself means secure _shell_, and that's not what the\nURL means - ssh is literaily just a transport layer for the git\nprotocol. This is not my invention but fairly standard thing which\nplenty of people use, and it makes it possible to select proper protocol\nhandlers and so on, shall something generic crunch on the URL. I've\nnever actually understood why do some people dislike it.\n\n> Jakub was also talking about support in gitweb for specifying\n> the location of submodules. It would be nice if admins could\n> set this information, wherever it ends up getting stored.\n\nHmm, this shouldn't be very hard to do if the support will get into\ngitweb. And adding the support to gitweb shouldn't be that hard either.\n:-) OTOH, it's not something that would get me terribly excited, so I\nguess I'll wait for the gitweb side.\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":"51628","messageId":"46D239AB.8060209@vilain.net","threadId":"9666","inReplyTo":"20070826235944.GM1219@pasky.or.cz","subject":"Re: repo.or.cz wishes?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-08-27T02:40:43Z","receivedAt":"2007-08-27T02:40:43Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Petr Baudis wrote:\n> Hi,\n>\n> I've just finally killed the HTTP auth for project administration that\n> was destroying everyone's lives, and added support for resetting\n> forgotten passwords, two main things that seemed to be the popular nits\n> of the repo.or.cz audience.\n>\n> So now I wonder, what is the thing you miss most there? Any cool stuff\n> repo.or.cz could (preferrably easily) do and doesn't?\n>\n> And please don't ask for smaller roundtrip times of requests for\n> administrator assistance. ;-)\n> \n\nI'd like to see the service mirrored, including potentially a repository\nwhich contains the meta/auth information (sans password hashes, perhaps)\nfor admins on accounts.\n\nThis of course opens a large can of worms when it comes to achieving\ndecentralization of the service as a whole, however I think those\nquestions will be best answered once the information is available for\nsetting up mirrors.\n\nI've also got hardware, bandwidth and some tuits.\n\nSam.\n"},{"id":"51651","messageId":"Pine.LNX.4.64.0708270933450.28586@racer.site","threadId":"9666","inReplyTo":"20070826235944.GM1219@pasky.or.cz","subject":"Re: repo.or.cz wishes?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-27T08:35:01Z","receivedAt":"2007-08-27T08:35:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 27 Aug 2007, Petr Baudis wrote:\n\n> So now I wonder, what is the thing you miss most there?\n\nI wonder if this is repo.or.cz specific, but we recently had a problem \nwhere the blobs of a project went away, and the forked project still \nrelied on them. Any ideas how to solve that issue?\n\nCiao,\nDscho\n"},{"id":"51737","messageId":"alpine.LFD.0.999.0708271114470.25853@woody.linux-foundation.org","threadId":"9666","inReplyTo":"20070827004153.GN1219@pasky.or.cz","subject":"Re: repo.or.cz wishes?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-27T18:23:52Z","receivedAt":"2007-08-27T18:23:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 27 Aug 2007, Petr Baudis wrote:\n\n> On Mon, Aug 27, 2007 at 02:16:34AM CEST, Sven Verdoolaege wrote:\n> > On Mon, Aug 27, 2007 at 01:59:44AM +0200, Petr Baudis wrote:\n> > > So now I wonder, what is the thing you miss most there? Any cool stuff\n> > > repo.or.cz could (preferrably easily) do and doesn't?\n> > \n> > Just a minor nit, but how about dropping the \"git+\" from the\n> > Push URL?\n> \n> I'm a major proponent of the \"git+\"\n\nI'd say \"only\", not \"major\".\n\nIt makes no sense.\n\n> - it's just the correct thing to specify. ssh:// by itself means secure \n> _shell_\n\nNo it isn't, and no it doesn't.\n\nIt makes no sense what-so-ever.\n\n\"ssh://\" is the *protocol*. What is actually done over the protocol is \nspecified by the program.\n\nThis is not at all git specific. Try running \"ssh\" vs \"scp\" some day, and \nyou'll notice the exact same thing: they both use the ssh _protocol_, but \nno, your statement that \"ssh://\" by itself means \"secure _shell_\" is total \nand utter garbage.\n\nIt means nothing at all of the kind. \n\n\"ssh://\" means the ssh protocol. It is that unambiguous, and that simple. \nSaying \"git+ssh://\" is totally idiotic, always has been, and always will \nbe.\n\nIt's as stupid as it would be to require people to say\n\n\tscp cp+ssh://host/filename .\n\nand nobody sane would *ever* advocate something that stupid. It's not how \nit's done.\n\nSo why do you continue to advocate \"git+ssh://\", when nobody else does, \nand several people have asked you not to.\n\nAnd yes, I realize that SVN does it. SVN for some unfathomable reason uses \n\"svn+ssh://\", but let's face it, the SVN developers have neither taste nor \nbrains. They don't know any better.\n\n\t\t\tLinus\n"},{"id":"51739","messageId":"7vir70ztvy.fsf@gitster.siamese.dyndns.org","threadId":"9666","inReplyTo":"alpine.LFD.0.999.0708271114470.25853@woody.linux-foundation.org","subject":"Re: repo.or.cz wishes?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-27T18:58:57Z","receivedAt":"2007-08-27T18:58:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 27 Aug 2007, Petr Baudis wrote:\n> ...\n> It's as stupid as it would be to require people to say\n>\n> \tscp cp+ssh://host/filename .\n>\n> and nobody sane would *ever* advocate something that stupid. It's not how \n> it's done.\n>\n> So why do you continue to advocate \"git+ssh://\", when nobody else does, \n> and several people have asked you not to.\n\nChuckles...\n\nI'd rather see hostname:/path/to/file on the page as it tends to\nbe even shorter.\n"},{"id":"51740","messageId":"vpqmywclrpl.fsf@bauges.imag.fr","threadId":"9666","inReplyTo":"alpine.LFD.0.999.0708271114470.25853@woody.linux-foundation.org","subject":"Re: repo.or.cz wishes?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-27T19:09:42Z","receivedAt":"2007-08-27T19:09:42Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Linus Torvalds writes:\n\n> It's as stupid as it would be to require people to say\n>\n> \tscp cp+ssh://host/filename .\n>\n> and nobody sane would *ever* advocate something that stupid. It's not how \n> it's done.\n\nYou could find a better example.\n\nscp doesn't accept URL syntax at all. So, no, it doesn't know about\ncp+ssh://, but doesn't know ssh:// either.\n\n-- \nMatthieu\n"},{"id":"51743","messageId":"20070827194957.GC20753@informatik.uni-freiburg.de","threadId":"9666","inReplyTo":"20070826235944.GM1219@pasky.or.cz","subject":"Re: repo.or.cz wishes?","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-08-27T19:49:57Z","receivedAt":"2007-08-27T19:49:57Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello Petr,\n\nPetr Baudis wrote:\n> So now I wonder, what is the thing you miss most there? Any cool stuff\n> repo.or.cz could (preferrably easily) do and doesn't?\nI have two wishes (even though I don't use repo.or.cz regularly).\n\n- searching for sha1 id.\n OK, I know how to create an URL for that, but that's inconvient.\n\n- When looking on forks of say git.git, I want the \"main\" project shown,\n too. That is http://repo.or.cz/w/git.git?a=forks should include a\n link to http://repo.or.cz/w/git.git.\n\nAfter rereading these may more be gitweb wishes than repo.or.cz, but\nanyhow ...\n\nBest regards\nUwe\n\n-- \nUwe Kleine-König\n\nhttp://www.google.com/search?q=half+a+cup+in+teaspoons\n"},{"id":"51749","messageId":"mj+md-20070827.195605.14967.albireo@ucw.cz","threadId":"9666","inReplyTo":"alpine.LFD.0.999.0708271114470.25853@woody.linux-foundation.org","subject":"Re: repo.or.cz wishes?","fromName":"Martin Mares","fromEmail":"mj@ucw.cz","sentAt":"2007-08-27T20:05:57Z","receivedAt":"2007-08-27T20:05:57Z","isPatch":false,"sender":{"key":"mj@ucw.cz","avatar":null},"body":"Hello, world!\\n\n\n> \"ssh://\" is the *protocol*. What is actually done over the protocol is \n> specified by the program.\n> \n> This is not at all git specific.\n\nReally?\n\nWhat does `ssh://what.the.hell.org/some/file' per se mean?\n\nSSH is a protocol, but rather in the sense similar to TLS, not to HTTP.\nIf it has some addressable objects, which could be referred to by the\npath part of the URL, they should be the programs to execute at the\nremote server, i.e., in our case the path to the GIT client binary,\nand certainly not the name of the repository, which has nothing to do\nwith the SSH protocol.\n\n(Just for completeness: I do not advocate using git+ssh, but your arguments\nagainst it look somewhat illogical.)\n\n\t\t\t\tHave a nice fortnight\n-- \nMartin `MJ' Mares http://mj.ucw.cz/\nFaculty of Math and Physics, Charles University, Prague, Czech Rep., Earth\nOnly dead fish swim with the stream.\n"},{"id":"51760","messageId":"20070827172729.wq6cdxhnk0o408sc@intranet.digizenstudio.com","threadId":"9666","inReplyTo":"mj+md-20070827.195605.14967.albireo@ucw.cz","subject":"Re: repo.or.cz wishes?","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2007-08-27T21:27:29Z","receivedAt":"2007-08-27T21:27:29Z","isPatch":false,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"\nQuoting Martin Mares :\n\n> What does `ssh://what.the.hell.org/some/file' per se mean?\n>\n> SSH is a protocol, but rather in the sense similar to TLS, not to HTTP.\n> If it has some addressable objects, which could be referred to by the\n> path part of the URL, they should be the programs to execute at the\n> remote server, i.e., in our case the path to the GIT client binary,\n> and certainly not the name of the repository, which has nothing to do\n> with the SSH protocol.\n\nNot to advocate either way (me being completely new to git), but as \nfar as ssh is concerned, I don't think that the addressable objects \nnecessarily have to be executables.\n\nQuoting RFC4251:\n\"The Secure Shell (SSH) Protocol is a protocol for secure remote login \nand other secure network services over an insecure network.\"\n\nThat reads rather vague to me.\n-- \nJing Xue\n"},{"id":"51756","messageId":"200708272358.43021.jnareb@gmail.com","threadId":"9666","inReplyTo":"20070827004153.GN1219@pasky.or.cz","subject":"Re: repo.or.cz wishes?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-27T21:58:42Z","receivedAt":"2007-08-27T21:58:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Monday, 27 August 2007, Petr \"Pasky\" Baudis wrote:\n> On Mon, Aug 27, 2007 at 02:16:34AM CEST, Sven Verdoolaege wrote:\n>> On Mon, Aug 27, 2007 at 01:59:44AM +0200, Petr Baudis wrote:\n>>>\n>>> So now I wonder, what is the thing you miss most there? Any cool stuff\n>>> repo.or.cz could (preferrably easily) do and doesn't?\n\nIs it now possible to _upload_ SSH key, instad of copy'n'paste it\nwhen creating repository/account?\n\nWould it be reasonable to limit repository name length, or at least\nmodify gitweb to truncate (cut) it if it is too long?\n\n>> Just a minor nit, but how about dropping the \"git+\" from the\n>> Push URL?\n> \n> I'm a major proponent of the \"git+\" - it's just the correct thing to\n> specify. ssh:// by itself means secure _shell_, and that's not what the\n> URL means - ssh is literaily just a transport layer for the git\n> protocol. This is not my invention but fairly standard thing which\n> plenty of people use, and it makes it possible to select proper protocol\n> handlers and so on, shall something generic crunch on the URL. I've\n> never actually understood why do some people dislike it.\n\nFirst, it is in the context of git, so one can say that \"git+\" is\nimplied. Documentation mentions only \"ssh://\". That said I prefer\n\"git+ssh://\" to \"ssh://\" alone.\n\nSecond, IIRC Linus prefers scp-like syntax for SSH protocol, namely\n\"[user]@host:/path/to/repo\", so perhaps that one should be used\ninstead.\n\n>> Jakub was also talking about support in gitweb for specifying\n>> the location of submodules. It would be nice if admins could\n>> set this information, wherever it ends up getting stored.\n> \n> Hmm, this shouldn't be very hard to do if the support will get into\n> gitweb. And adding the support to gitweb shouldn't be that hard either.\n> :-) OTOH, it's not something that would get me terribly excited, so I\n> guess I'll wait for the gitweb side.\n\nThe problem is that repo.or.cz needs support for that in gitweb, while\ngitweb in turn needs support for that in git. This needs git consensus\non how to specify object database location (or just gitdir) for\nsubmodules, to have later submodule support in gitweb.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"51765","messageId":"alpine.LFD.0.999.0708271509230.25853@woody.linux-foundation.org","threadId":"9666","inReplyTo":"mj+md-20070827.195605.14967.albireo@ucw.cz","subject":"Re: repo.or.cz wishes?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-27T22:27:07Z","receivedAt":"2007-08-27T22:27:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 27 Aug 2007, Martin Mares wrote:\n> \n> What does `ssh://what.the.hell.org/some/file' per se mean?\n\nSo what does \"http://what.the.hell.org/some/file\" mean?\n\nDoes it mean that you have to start a web browser? Should we make that be\n\n\tgit+http://what.the.hell.org/some/file\n\nto make it clear that we're doing \"git work\" over the \"http\" protocol?\n\nPretty obviously not.\n\n> SSH is a protocol, but rather in the sense similar to TLS, not to HTTP.\n\nWhat does *that* mean? A protocol is a protocol. Your argument that \nprotocols are \"different\" is pointless. Some protocols are usable for git, \nothers aren't. OF COURSE different protocols are different. They are \ndifferent in different ways.\n\nGit uses URL's to say how to access something, which includes a protocol, \nan optional host, and a location within the host. It's quite obvious what \nthey mean, and it's *also* obvious that the meaning is git-specific. \n\nHere's what it boils down to:\n\n - do you think it is sensible to write\n\n\tgit clone git+file:///some/directory\n\tgit clone git+http://host/directory\n\tgit clone git+rsync://host/directory\n\n when cloning from the local filesystem, over http, or over rsync \n respectively? The first one, btw, actually uses the \"git protocol\". The \n two others do not, but since a user shouldn't care, it would be really \n stupid to try to make some internal implementation detail show up in \n the URL scheme.\n\n - if you really think that the above is sensible, then explain why.\n\n - if you think that is TOTALLY IDIOTIC, then explain why \"ssh://\" is so \n magically special that it would somehow make sense to say \"git+\" for \n it?\n\nAs to your TLS example: if we were to do \"git over TLS\", it would make \nperfect sense to use either \"tls://\" (although \"gits://\" might be more \nnatural, not because tls is wrong, but because people have gotten used to \n\"https://\") if we were to have a \"secure git\" port. Or maybe we'd use the \nsame port number that we already have assigned for git, and just add some \n\"use TLS to authenticate/encrypt\", and use \"tls://\" for that. It makes \nperfect sense.\n\nIn short: you should just ask yourself: what is the most natural thing for \na *user* to type to \"git clone\". And no, the \"git+\" prefix never makes \nsense.\n\n\t\t\tLinus\n"},{"id":"51763","messageId":"46D356F9.1010506@vilain.net","threadId":"9666","inReplyTo":"alpine.LFD.0.999.0708271509230.25853@woody.linux-foundation.org","subject":"Re: repo.or.cz wishes?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-08-27T22:58:01Z","receivedAt":"2007-08-27T22:58:01Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> - if you really think that the above is sensible, then explain why.\n> \n> - if you think that is TOTALLY IDIOTIC, then explain why \"ssh://\" is so \n> magically special that it would somehow make sense to say \"git+\" for \n> it?\n\nThis is also useful for foreign SCM support; the idea of supporting\nsvn+ssh:// \"directly\" with git remote and the likes.\n\nI don't usually write git+ssh://, but I do consider it to be the form\nwhich is more in the spirit of application interoperability. It says\nwhat it is, which is ssh tunnelled git protocol.\n\n> As to your TLS example: if we were to do \"git over TLS\", it would make \n> perfect sense to use either \"tls://\" (although \"gits://\" might be more \n> natural, not because tls is wrong, but because people have gotten used to \n> \"https://\") if we were to have a \"secure git\" port. Or maybe we'd use the \n> same port number that we already have assigned for git, and just add some \n> \"use TLS to authenticate/encrypt\", and use \"tls://\" for that. It makes \n> perfect sense.\n\nThe scheme is bad because it doesn't integrate with other appliations.\nSeeing the URI in a web page they have no way of knowing which\napplication or port this tls:// URI refers to. It's not *universal*.\n\nThis is fine for URIs passed into git, but bad if you want to link to it\nfrom elsewhere.\n\nSam.\n"},{"id":"51762","messageId":"200708280116.00537.jnareb@gmail.com","threadId":"9666","inReplyTo":"alpine.LFD.0.999.0708271509230.25853@woody.linux-foundation.org","subject":"Re: repo.or.cz wishes?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-27T23:16:00Z","receivedAt":"2007-08-27T23:16:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> As to your TLS example: if we were to do \"git over TLS\", it would make \n> perfect sense to use either \"tls://\" (although \"gits://\" might be more \n> natural, not because tls is wrong, but because people have gotten used to \n> \"https://\") if we were to have a \"secure git\" port. Or maybe we'd use the \n> same port number that we already have assigned for git, and just add some \n> \"use TLS to authenticate/encrypt\", and use \"tls://\" for that. It makes \n> perfect sense.\n\nI like gits:// idea for \"git over TLS\", and I'm against \"tls://\". I wonder\nif it would be hard to implement \"git overt TLS\"? We could resurrect patch\nwhich allowed push over git protocol, onnly restricting pushing to gits\nprotocol.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"51761","messageId":"alpine.LFD.0.999.0708271616520.25853@woody.linux-foundation.org","threadId":"9666","inReplyTo":"46D356F9.1010506@vilain.net","subject":"Re: repo.or.cz wishes?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-27T23:17:45Z","receivedAt":"2007-08-27T23:17:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Aug 2007, Sam Vilain wrote:\n> \n> This is fine for URIs passed into git, but bad if you want to link to it\n> from elsewhere.\n\n..and by that logic, you should add \"git+\" to *everything*, not just ssh.\n\nWhich simply isn't practical or sane - only damn annoying.\n\n\t\t\tLinus\n"},{"id":"51766","messageId":"200708280127.47808.jnareb@gmail.com","threadId":"9666","inReplyTo":"alpine.LFD.0.999.0708271616520.25853@woody.linux-foundation.org","subject":"Re: repo.or.cz wishes?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-27T23:27:47Z","receivedAt":"2007-08-27T23:27:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Tue, 28 Aug 2007, Sam Vilain wrote:\n> > \n> > This is fine for URIs passed into git, but bad if you want to link to it\n> > from elsewhere.\n> \n> ..and by that logic, you should add \"git+\" to *everything*, not just ssh.\n> \n> Which simply isn't practical or sane - only damn annoying.\n\nNot exactly. You can browse using http:// and file:// protocols,\nrsync:// is simply rsync, while ssh:// (or git_ssh://) can be limited\nusing git-shell.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"51772","messageId":"46D35E8A.8010409@vilain.net","threadId":"9666","inReplyTo":"alpine.LFD.0.999.0708271616520.25853@woody.linux-foundation.org","subject":"Re: repo.or.cz wishes?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-08-27T23:30:18Z","receivedAt":"2007-08-27T23:30:18Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> \n> On Tue, 28 Aug 2007, Sam Vilain wrote:\n>> This is fine for URIs passed into git, but bad if you want to link to it\n>> from elsewhere.\n> \n> ..and by that logic, you should add \"git+\" to *everything*, not just ssh.\n> Which simply isn't practical or sane - only damn annoying.\n\nWhy annoying and impractical, if you don't ever have to specify it\nunless you want to write a URI which is portable between applications?\n\nSam.\n"},{"id":"51770","messageId":"alpine.LFD.0.999.0708271632000.25853@woody.linux-foundation.org","threadId":"9666","inReplyTo":"46D35E8A.8010409@vilain.net","subject":"Re: repo.or.cz wishes?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-27T23:34:37Z","receivedAt":"2007-08-27T23:34:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Aug 2007, Sam Vilain wrote:\n> \n> Why annoying and impractical, if you don't ever have to specify it\n> unless you want to write a URI which is portable between applications?\n\nSure. I'm perfectly happy to make connect.c just ignore any \"git+\" prefix, \nand let people do it.\n\nWhat I object to is:\n - the totally *idiotic* notion that \"ssh\" is somehow different\n - encouraging people to actually *use* that inconvenient format\n\nThe fact is, nobody really cares. We've happily used the non-\"git+\" forms \nfor over two years, and there has never *ever* been a case of actual \nconfusion. So allowing the \"git+\" prefix everywhere may be _logical_, but \nit's still totally idiotic and user-unfriendly.\n\n\t\tLinus\n"},{"id":"51768","messageId":"alpine.LFD.0.999.0708271635170.25853@woody.linux-foundation.org","threadId":"9666","inReplyTo":"200708280127.47808.jnareb@gmail.com","subject":"Re: repo.or.cz wishes?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-27T23:38:48Z","receivedAt":"2007-08-27T23:38:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Aug 2007, Jakub Narebski wrote:\n> \n> Not exactly. You can browse using http:// and file:// protocols,\n> rsync:// is simply rsync, while ssh:// (or git_ssh://) can be limited\n> using git-shell.\n\nBullshit. You carefully left out \"git://\", since that doesn't fit your \n\"argument\".\n\nThe fact is, all git URL's make sense for *git*, not necessarily for \nanything else. They may have incidental meanings outside of git, but \ncertainly nothing that is really *sensible*.\n\nAnd that is how it was designed to be. The URL's are for *git*, not for \nother uses. If you want to do cross-SCM tools, you need to let them know \nit's a \"git\" thing wheher it's browsable or not, so the argument that ssh \nis something \"different\" is bogus crapola.\n\nJust face it, ssh is in no way different from any of the other git URL \nspecifiers. \n\n\t\t\tLinus\n"},{"id":"51774","messageId":"20070829073212.GQ1976MdfPADPa@greensroom.kotnet.org","threadId":"9666","inReplyTo":"200708282356.10605.jnareb@gmail.com","subject":"Re: repo.or.cz wishes?","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-08-29T07:32:12Z","receivedAt":"2007-08-29T07:32:12Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Tue, Aug 28, 2007 at 11:56:10PM +0200, Jakub Narebski wrote:\n> On Tue, 28 August 2007, Sven Verdoolaege wrote:\n> > On Mon, Aug 27, 2007 at 11:58:42PM +0200, Jakub Narebski wrote:\n> >>\n> >> The problem is that repo.or.cz needs support for that in gitweb, while\n> >> gitweb in turn needs support for that in git. This needs git consensus\n> >> on how to specify object database location (or just gitdir) for\n> >> submodules, to have later submodule support in gitweb.\n> > \n> > What would be the use of that (outside of gitweb) ?\n> \n> For the hypothetical (planned?) future '--recurse-submodules' option\n> to git-diff family, git-ls-tree and git-ls-files, git-fetch and git-push\n> (but I think not git-pull), perhaps git-log (besides what it supports\n> by the way of git-diff-tree), maybe even git-status and git-commit.\n\nAh... you're talking about bare repositories, right?\nFor non-bare repos, I'd assume you would only recurse for those\nsubmodules that you have actually checked out in your working tree.\n\nskimo\n"},{"id":"51793","messageId":"20070829095400.GF1219@pasky.or.cz","threadId":"9666","inReplyTo":"20070829042005.GT18160@spearce.org","subject":"Re: repo.or.cz wishes?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-29T09:54:00Z","receivedAt":"2007-08-29T09:54:00Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Aug 29, 2007 at 06:20:05AM CEST, Shawn O. Pearce wrote:\n> Johannes Schindelin wrote:\n> > On Tue, 28 Aug 2007, Theodore Tso wrote:\n> > > On Tue, Aug 28, 2007 at 12:10:59AM -0400, Shawn O. Pearce wrote:\n> > > > At day-job I have a hard rule that you cannot even push into an A, let \n> > > > alone rewind a branch in it or delete a branch from it.\n> > > \n> > > Why don't you even allow people to push into A? That should be safe....\n> > \n> > Nope:\n> > \n> > for b in $(git ls-remote /that/other/repo | sed \"s/^[^ ]* //\")\n> > do\n> > \tgit push /that/other/repo :$b\n> > done\n> \n> Well, at day-job I use contrib/hooks/update-paranoid to deny all\n> push access into my A's (/that/other/repo). But that could just\n> as easily be configured to allow branch creation and branch update\n> (fast-forward) but no rewind or delete.\n> \n> When I symlink A's refs into B I also don't allow B to update,\n> create, rewind or delete the symlinked refs via push. This way\n> you can't do something weird to A like upload new objects into B's\n> ODB but then change A's refs to point to objects that A's own ODB\n> doesn't have.\n> \n> Hmm, I wonder of Pasky handles that correctly on repo.or.cz...\n\nI don't handle it at all, but if you don't have permissions to modify A\nyou simply won't be able to do anything weird to A. If you have the\npermissions, I'm still not sure if Git will keep symlinked refs over\nref updates; if so, hey, you had the permissions for A and it's your\nreponsibility if you screw up.\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":"51794","messageId":"20070829095818.GG1219@pasky.or.cz","threadId":"9666","inReplyTo":"7vr6lnszay.fsf@gitster.siamese.dyndns.org","subject":"Re: repo.or.cz wishes?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-29T09:58:18Z","receivedAt":"2007-08-29T09:58:18Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Aug 29, 2007 at 07:08:21AM CEST, Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > Theodore Tso wrote:\n> >> On Tue, Aug 28, 2007 at 12:10:59AM -0400, Shawn O. Pearce wrote:\n> >> > Its what happens when you use `git clone --shared A B` and the\n> > ...\n> >> This has been discussed before, and it wouldn't be *that* hard to have\n> >> \"git clone --shared\" create a backpointer from B to A, so that\n> >> \"git-prune\" could also search the B's refs and not prune anything that\n> >> is in A which is reachable from heads in A and B.\n> >\n> > Not if I already have a pointer from B to A's refs. repo.or.cz\n> > also has this same pointer:\n> >\n> > \tgit clone --shared A B\n> > \tln -s A/refs B/refs/forkee\n> \n> Two things to watch out for are (1) packed refs won't be\n> protected with this trick, and (2) symrefs in refs/ hierarchy\n> will point at wrong place if you did this. The latter hopefully\n> won't be a problem because the trick being discussed is only to\n> add reachability and not _using_ the borrowed refs for anything\n> (iow, this makes B/refs/forkee/remote/origin/HEAD incorrectly\n> point at refs/remotes/origin/master, but what it really should\n> point at is B/refs/forkee/remote/origin/master).\n\nBTW gitweb actually uses refs/forkee/ to add funny ref tags to commits,\nwhich was completely unintended but is actually in the end quite handy\n(though the tags should be modified to look less confusing).\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":"51807","messageId":"20070829111345.GD29615@thunk.org","threadId":"9666","inReplyTo":"20070829041523.GS18160@spearce.org","subject":"Re: repo.or.cz wishes?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-08-29T11:13:45Z","receivedAt":"2007-08-29T11:13:45Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Aug 29, 2007 at 12:15:23AM -0400, Shawn O. Pearce wrote:\n> > This is morally the same, but it makes the hardlink step easier (only\n> > one pack to link from A to B), and by using git-gc mit makes it\n> > conceptually easier for people to understand what's going on.\n> > \n> > git --git-dir=A gc\n> > ln A/.git/objects/pack/* B/.git/objects/pack\n> > git --git-dir=B gc --prune\n> > git --git-dir=A prune\n> \n> No, it won't work.\n> \n> The problem is that during the first `git --git-dir=A gc` call\n> you are deleting packfiles that may contain objects that B needs.\n> *poof*. \n\nBut \"git-gc\" without the --prune doesn't delete any objects. So it\nshould always be safe to use git-gc even if there are repositories\nthat are relying on that repo's ODB. It's only if you use git-gc\n--prune that you could get in troudble. It might delete some\npackfiles containing objects needed by B, but only after consolidating\nall of the objects into a single packfile that contains all of the\nobjects that had always been in A's ODB.\n\nSo I don't see why this wouldn't work.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"51839","messageId":"alpine.LFD.0.999.0708291009570.25853@woody.linux-foundation.org","threadId":"9666","inReplyTo":"20070829041523.GS18160@spearce.org","subject":"Re: repo.or.cz wishes?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-29T17:11:33Z","receivedAt":"2007-08-29T17:11:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 29 Aug 2007, Shawn O. Pearce wrote:\n> \n> Not if I already have a pointer from B to A's refs. repo.or.cz\n> also has this same pointer:\n> \n> \tgit clone --shared A B\n> \tln -s A/refs B/refs/forkee\n\nNow, this doesn't work well with packed refs, I'm afraid.\n\nSo I suspect that if we really want to support something like this, we'd \nneed to do more than just avoid the recursion when you cross-link.\n\n\t\tLinus\n"},{"id":"51860","messageId":"200708300112.51666.jnareb@gmail.com","threadId":"9666","inReplyTo":"20070829073212.GQ1976MdfPADPa@greensroom.kotnet.org","subject":"Re: repo.or.cz wishes?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-29T23:12:51Z","receivedAt":"2007-08-29T23:12:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, Aug 29, 2007, Sven Verdoolaege wrote:\n> On Tue, Aug 28, 2007 at 11:56:10PM +0200, Jakub Narebski wrote:\n>> On Tue, 28 August 2007, Sven Verdoolaege wrote:\n>>> On Mon, Aug 27, 2007 at 11:58:42PM +0200, Jakub Narebski wrote:\n>>>>\n>>>> The problem is that repo.or.cz needs support for that in gitweb, while\n>>>> gitweb in turn needs support for that in git. This needs git consensus\n>>>> on how to specify object database location (or just gitdir) for\n>>>> submodules, to have later submodule support in gitweb.\n>>> \n>>> What would be the use of that (outside of gitweb) ?\n>> \n>> For the hypothetical (planned?) future '--recurse-submodules' option\n>> to git-diff family, git-ls-tree and git-ls-files, git-fetch and git-push\n>> (but I think not git-pull), perhaps git-log (besides what it supports\n>> by the way of git-diff-tree), maybe even git-status and git-commit.\n> \n> Ah... you're talking about bare repositories, right?\n> For non-bare repos, I'd assume you would only recurse for those\n> submodules that you have actually checked out in your working tree.\n\nFor bare repositories, and for repositories which move around (at least\nonce change path). Gitweb uses repository like it is bare...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"52081","messageId":"20070831210938.GC18160@spearce.org","threadId":"9666","inReplyTo":"20070829111345.GD29615@thunk.org","subject":"Re: repo.or.cz wishes?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-31T21:09:39Z","receivedAt":"2007-08-31T21:09:39Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Theodore Tso wrote:\n> On Wed, Aug 29, 2007 at 12:15:23AM -0400, Shawn O. Pearce wrote:\n> > > \n> > > git --git-dir=A gc\n> > > ln A/.git/objects/pack/* B/.git/objects/pack\n> > > git --git-dir=B gc --prune\n> > > git --git-dir=A prune\n> > \n> > No, it won't work.\n> > \n> > The problem is that during the first `git --git-dir=A gc` call\n> > you are deleting packfiles that may contain objects that B needs.\n> > *poof*. \n> \n> But \"git-gc\" without the --prune doesn't delete any objects.\n\nYes, it does delete objects. Even without --prune. That is\nbecause git-gc is running `git-repack -a -d -l`. repack -a means\nrepack all objects reachable from the current refs. The -d means\ndelete the packfiles that existed when the repack started, as it\nis assumed that all needed (reachable) objects were copied into\nthe new output packfile(s). The -d also means delete any loose\nobjects that are now packed (git-prune-packed).\n\nYet there may be objects in A that A cannot reach anymore (deleted\nor rewound branch) but that B needs and B does not have a copy of.\nIf these objects were in one of the prior packfiles of A and is\nnot in the new packfile(s) of A then those objects are gone. *poof*.\n\n> So it\n> should always be safe to use git-gc even if there are repositories\n> that are relying on that repo's ODB. It's only if you use git-gc\n> --prune that you could get in troudble. It might delete some\n> packfiles containing objects needed by B, but only after consolidating\n> all of the objects into a single packfile that contains all of the\n> objects that had always been in A's ODB.\n\nBut when we repack we don't repack everything in A's ODB, we only\nrepack the things that A can reach. If A cannot reach something\nbecause a branch was rewound or deleted it won't survive the repack.\nThen the repack is behaving like at least partially like gc --prune.\n \n> So I don't see why this wouldn't work.\n\nIt only works if A cannot delete a branch or rewind a branch.\nIn other words, once an object is stored in A's ODB it must always\nbe reachable from A's refs.\n\n-- \nShawn.\n"},{"id":"52118","messageId":"20070901025857.GD18160@spearce.org","threadId":"9666","inReplyTo":"alpine.LFD.0.999.0708291009570.25853@woody.linux-foundation.org","subject":"Re: repo.or.cz wishes?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-09-01T02:58:57Z","receivedAt":"2007-09-01T02:58:57Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Wed, 29 Aug 2007, Shawn O. Pearce wrote:\n> > \n> > Not if I already have a pointer from B to A's refs. repo.or.cz\n> > also has this same pointer:\n> > \n> > \tgit clone --shared A B\n> > \tln -s A/refs B/refs/forkee\n> \n> Now, this doesn't work well with packed refs, I'm afraid.\n\nNo, it doesn't work well. So I actually also avoid packing A's refs.\nWhich is yet another reason why my A's don't allow pushing, that\nway nobody goes nuts and creates a ton of refs in there. With only\nrefs/heads/master and it being unpacked its not a big deal.\n \n> So I suspect that if we really want to support something like this, we'd \n> need to do more than just avoid the recursion when you cross-link.\n\nYes. I've been thinking about trying to better share the ODB and\nthe ref database between repositories, but it has been low priority\nfor me.\n\nI rely on this ref symlinking/alternate ODB trick a lot at day-job\nto help me cope with an ugly situation I created across a number of\nrepositories. Most of our codebase came from one Git repository,\nbut has been refactored and split into about 10 different Git\nrepositories. I did that refactoring by just cloning and deleting\nthe uninteresting content, so each repository actually has a huge\nblock of its history in common with the other 9.\n\nOne such A is \"common-crap.git\" that is the shared common history.\nSince its strictly history nobody changes that repository, and\neveryone borrows objects from it. This reduces my common working\nset by about 900MiB, as the history lives in only one packfile and\nnot in 10.\n\nThere are obviously other ways to deal with this:\n\n - start the 10 repositories over again and use info/grafts to\n reinsert the old history when/if required;\n\n - just hardlink the same .keep'd packfile into the 10 repositories,\n since it is held by .keep it won't be touched during repack.\n\nSo one reason it has been low priority for me to improve upon is\nbecause there's more than one way to solve the problem, and the\nparticular solution I have settled upon may not be the best solution\nfor anyone.\n\nThough I think we can all agree that repo.or.cz's use of forks\nis increasingly more popular, and one of the more powerful social\nfeatures of git. Better supporting it out of the box by making it\neasier to setup and manage can only be a good thing for our users.\n\n-- \nShawn.\n"}]}