{"thread":{"id":"20839","subject":"[PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","startedAt":"2009-09-04T02:13:49Z","lastAt":"2009-09-04T22:36:40Z","messageCount":18,"participants":["Daniel Barkalow","Sverre Rabbelier","Mike Ralphson","Johannes Schindelin","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":8},"messages":[{"id":"122377","messageId":"alpine.LNX.2.00.0909032213180.28290@iabervon.org","threadId":"20839","inReplyTo":null,"subject":"[PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-09-04T02:13:49Z","receivedAt":"2009-09-04T02:13:49Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"Instead of trying to make http://, https://, and ftp:// URLs\nindicative of some sort of pattern of transport helper usage, make\nthem a special case which runs the \"curl\" helper, and leave the\nmechanism by which arbitrary helpers will be chosen entirely to future\nwork.\n\nSigned-off-by: Daniel Barkalow \n---\n Makefile | 17 ++---------------\n transport-helper.c | 7 ++-----\n transport.c | 2 +-\n transport.h | 2 +-\n 4 files changed, 6 insertions(+), 22 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 263e191..3ac12ec 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -972,8 +972,7 @@ else\n \telse\n \t\tCURL_LIBCURL = -lcurl\n \tendif\n-\tCURL_SYNONYMS = git-remote-https$X git-remote-ftp$X\n-\tPROGRAMS += git-remote-http$X $(CURL_SYNONYMS) git-http-fetch$X\n+\tPROGRAMS += git-remote-curl$X git-http-fetch$X\n \tcurl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)\n \tifeq \"$(curl_check)\" \"070908\"\n \t\tifndef NO_EXPAT\n@@ -1483,16 +1482,10 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n \t\t$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)\n \n-git-remote-http$X: remote-curl.o http.o http-walker.o $(GITLIBS)\n+git-remote-curl$X: remote-curl.o http.o http-walker.o $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n \t\t$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)\n \n-$(CURL_SYNONYMS): git-remote-http$X\n-\t$(QUIET_LNCP)$(RM) $@ && \\\n-\tln $< $@ 2>/dev/null || \\\n-\tln -s $< $@ 2>/dev/null || \\\n-\tcp $< $@\n-\n $(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)\n $(patsubst git-%$X,%.o,$(PROGRAMS)) git.o: $(LIB_H) $(wildcard */*.h)\n builtin-revert.o wt-status.o: wt-status.h\n@@ -1674,12 +1667,6 @@ endif\n \t\tln -s \"git$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n \t\tcp \"$$execdir/git$X\" \"$$execdir/$$p\" || exit; \\\n \t done; } && \\\n-\t{ for p in $(CURL_SYNONYMS); do \\\n-\t\t$(RM) \"$$execdir/$$p\" && \\\n-\t\tln \"$$execdir/git-remote-http$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n-\t\tln -s \"git-remote-http$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n-\t\tcp \"$$execdir/git-remote-http$X\" \"$$execdir/$$p\" || exit; \\\n-\t done; } && \\\n \t./check_bindir \"z$$bindir\" \"z$$execdir\" \"$$bindir/git-add$X\"\n \n install-doc:\ndiff --git a/transport-helper.c b/transport-helper.c\nindex 43fdc0a..4684877 100644\n--- a/transport-helper.c\n+++ b/transport-helper.c\n@@ -152,13 +152,10 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)\n \treturn ret;\n }\n \n-int transport_helper_init(struct transport *transport)\n+int transport_helper_init(struct transport *transport, const char *name)\n {\n \tstruct helper_data *data = xcalloc(sizeof(*data), 1);\n-\tchar *eom = strchr(transport->url, ':');\n-\tif (!eom)\n-\t\treturn -1;\n-\tdata->name = xstrndup(transport->url, eom - transport->url);\n+\tdata->name = name;\n \n \ttransport->data = data;\n \ttransport->get_refs_list = get_refs_list;\ndiff --git a/transport.c b/transport.c\nindex f2bd998..4cb8077 100644\n--- a/transport.c\n+++ b/transport.c\n@@ -823,7 +823,7 @@ struct transport *transport_get(struct remote *remote, const char *url)\n \t} else if (!prefixcmp(url, \"http://\")\n \t || !prefixcmp(url, \"https://\")\n \t || !prefixcmp(url, \"ftp://\")) {\n-\t\ttransport_helper_init(ret);\n+\t\ttransport_helper_init(ret, \"curl\");\n #ifdef NO_CURL\n \t\terror(\"git was compiled without libcurl support.\");\n #else\ndiff --git a/transport.h b/transport.h\nindex bfd542f..c14da6f 100644\n--- a/transport.h\n+++ b/transport.h\n@@ -80,6 +80,6 @@ int transport_disconnect(struct transport *transport);\n char *transport_anonymize_url(const char *url);\n \n /* Transport methods defined outside transport.c */\n-int transport_helper_init(struct transport *transport);\n+int transport_helper_init(struct transport *transport, const char *name);\n \n #endif\n-- \n1.6.4.2.419.gc86f8\n"},{"id":"122388","messageId":"fabb9a1e0909032229k5e6e2ed5mc11e8ff9c16dfcc0@mail.gmail.com","threadId":"20839","inReplyTo":"alpine.LNX.2.00.0909032213180.28290@iabervon.org","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-09-04T05:29:23Z","receivedAt":"2009-09-04T05:29:23Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Sep 4, 2009 at 04:13, Daniel Barkalow wrote:\n> Instead of trying to make http://, https://, and ftp:// URLs\n> indicative of some sort of pattern of transport helper usage, make\n> them a special case which runs the \"curl\" helper, and leave the\n> mechanism by which arbitrary helpers will be chosen entirely to future\n> work.\n\nI'm sorry, I missed a few emails I think :(. Would you mind explaining\nwhy we chose to special-case the curl helpers instead of the symlink\nscheme?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"122400","messageId":"e2b179460909040204yb809738p54066430591d161b@mail.gmail.com","threadId":"20839","inReplyTo":"alpine.LNX.2.00.0909032213180.28290@iabervon.org","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2009-09-04T09:04:46Z","receivedAt":"2009-09-04T09:04:46Z","isPatch":true,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2009/9/4 Daniel Barkalow :\n> Instead of trying to make http://, https://, and ftp:// URLs\n> indicative of some sort of pattern of transport helper usage, make\n> them a special case which runs the \"curl\" helper, and leave the\n> mechanism by which arbitrary helpers will be chosen entirely to future\n> work.\n\n> -       PROGRAMS += git-remote-http$X $(CURL_SYNONYMS) git-http-fetch$X\n> +       PROGRAMS += git-remote-curl$X git-http-fetch$X\n\nI think .gitignore would need to be updated again with the added and\nremoved executables?\n\nMike\n"},{"id":"122408","messageId":"alpine.DEB.1.00.0909041232500.4605@intel-tinevez-2-302","threadId":"20839","inReplyTo":"alpine.LNX.2.00.0909032213180.28290@iabervon.org","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-09-04T10:34:59Z","receivedAt":"2009-09-04T10:34:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 3 Sep 2009, Daniel Barkalow wrote:\n\n> Instead of trying to make http://, https://, and ftp:// URLs indicative \n> of some sort of pattern of transport helper usage, make them a special \n> case which runs the \"curl\" helper, and leave the mechanism by which \n> arbitrary helpers will be chosen entirely to future work.\n\nI have to admit that this does not convince me at all.\n\nThe special case is \"http://\" and \"https://\" which might indicate foreign \nVCS repositories.\n\nIn all other cases, I am afraid that you are complicating the glove.\n\nRemember: the whole purpose of the \"foreign VCS\" helpers is user \nconvenience.\n\nCiao,\nDscho\n"},{"id":"122411","messageId":"fabb9a1e0909040347i2a002c62h47f8d39596134095@mail.gmail.com","threadId":"20839","inReplyTo":"20090904172345.6117@nanako3.lavabit.com","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-09-04T10:47:14Z","receivedAt":"2009-09-04T10:47:14Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Sep 4, 2009 at 10:23, Nanako Shiraishi wrote:\n>  http://thread.gmane.org/gmane.comp.version-control.git/127121/focus=127520\n\nI don't see anything in that thread that convinces me why this is the\nbetter solution. Unless I'm reading it wrong Junio said \"so this is\nhow you're going to do it\", and Daniel said \"yup\".\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"122412","messageId":"7vk50fugpn.fsf@alter.siamese.dyndns.org","threadId":"20839","inReplyTo":"alpine.DEB.1.00.0909041232500.4605@intel-tinevez-2-302","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-04T10:50:12Z","receivedAt":"2009-09-04T10:50:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> The special case is \"http://\" and \"https://\" which might indicate foreign \n> VCS repositories.\n>\n> In all other cases, I am afraid that you are complicating the glove.\n>\n> Remember: the whole purpose of the \"foreign VCS\" helpers is user \n> convenience.\n\nSorry, but you completely lost me here.\n\nHere are two URLs that follows your \"user convenience\" principle.\n\n\thttp://example.xz/repos/frotz.git/\n\thttp://example.xz/repo/frotz/trunk/\n\nHow do you tell, without relying on .git and trunk, the former is a git\nrepository and wants the dumb walker transport to fetch from, while the\nlatter is probably a svn and you would either use \"svn checkout\", or use\n\"git clone\" on it via the svn helper?\n\nWell, you don't.\n\nOne possible \"convenient user interface\" would be to say\n\n\tsvn+http://example.xz/repo/frotz/trunk/\n\n(or use :: instead of + as the helper-name separator, as we agreed not to\ndecide on it)\n \nThis would give us\n\n (1) it is clear that it literally is what you would give to git and\n trigger the svn helper; and\n\n (2) to people who know how canonical git URLs with foreign helper are\n spelled, it also is clear that you can use \"svn checkout\" on\n everything after \"svn+\" in it.\n\n A corollary to this is that you can also use \"git svn init\" on it.\n\nCompared to that, if you do not have any such prefix, how would that be\nmore convenient to the users?\n\nOr perhaps you have an alternative in mind that is more convenient for the\nusers and that is not \"use identically looking http://... for both\", but\nyou are being unnecessarily cryptic by not spelling out what it is.\n"},{"id":"122428","messageId":"alpine.DEB.1.00.0909041323170.4605@intel-tinevez-2-302","threadId":"20839","inReplyTo":"7vk50fugpn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-09-04T12:33:27Z","receivedAt":"2009-09-04T12:33:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 4 Sep 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > The special case is \"http://\" and \"https://\" which might indicate foreign \n> > VCS repositories.\n> >\n> > In all other cases, I am afraid that you are complicating the glove.\n> >\n> > Remember: the whole purpose of the \"foreign VCS\" helpers is user \n> > convenience.\n> \n> Sorry, but you completely lost me here.\n\nMy point was that the ambiguity _only_ applies to http:// and https:// \nURLs, as you illustrated yourself:\n\n> Here are two URLs that follows your \"user convenience\" principle.\n> \n> \thttp://example.xz/repos/frotz.git/\n> \thttp://example.xz/repo/frotz/trunk/\n\nThere is no ambiguity about hg://, svn://, etc. None.\n\nSome \"URLs\" do not look like \"URLs\" at all, e.g. :ext:user@host:/module \nfor CVS repositories. I haven't really thought about a convenient way to \nspecify these, but I could imagine that indeed something like \n\"cvs::ext:usr@host:/module\" would make sense, and still be an intuitive \ninterface that does not break down with \"git clone\".\n\nLikewise, I imagine that \"svn::http://example.xz/repo/frotz/trunk\" (or \neven \"svn::std::http://example.xz/repo/frotz\") are not _too_ unintuitive.\n\nBut my real point still stands: \"git clone hg://example.xz/repos/blub\" \nshould Just Work.\n\nOh, and I definitely do not want to expose an _implementation detail_ such \nas \"we use cURL\" in the name of the remote helper. That would just be bad \nstyle in my book.\n\n> How do you tell, without relying on .git and trunk, the former is a git \n> repository and wants the dumb walker transport to fetch from, while the \n> latter is probably a svn and you would either use \"svn checkout\", or use \n> \"git clone\" on it via the svn helper?\n> \n> Well, you don't.\n> \n> One possible \"convenient user interface\" would be to say\n> \n> \tsvn+http://example.xz/repo/frotz/trunk/\n> \n> (or use :: instead of + as the helper-name separator, as we agreed not to\n> decide on it)\n\nNow that you mention it, the main issue was the ambiguity that\n\n\tsvn:/path/to/repo\n\nshould actually be an ssh \"URL\". But I think that the simple fact that a \n\"://\" in the URL (and if that is not sufficient, something like a \n\"::\" prefix) make non-ssh URLs distinct enough to decide robustly \nwhat type the URL is.\n\n> This would give us\n> \n> (1) it is clear that it literally is what you would give to git and\n> trigger the svn helper; and\n> \n> (2) to people who know how canonical git URLs with foreign helper are\n> spelled, it also is clear that you can use \"svn checkout\" on\n> everything after \"svn+\" in it.\n\nThe only problem is that you cannot use \"git-remote-svn+http\" as helper, \nas \"+\" are not valid filename characters on Windows. However, you could \nhave a \"git-remote-svn\" handling both \"svn://\" and \"svn+\" prefixes.\n\n> Compared to that, if you do not have any such prefix, how would that be \n> more convenient to the users?\n\nIndeed, I made myself misunderstood. I think that for _a lot_ of \nrepository URLs, there are naturally distinctive-enough prefixes. IMHO we \nshould make use of that, for a substantially improved user experience (as \nopposed to, say, the user experience for unfortunate CVS users who would \nlike to establish a git-svn-like workflow).\n\nSummary: I think that for most URLs, \"://\" is enough to tell \nwhich helper to call (\"http://\" means Git, tough).\n\nFor those URLs, where this is not sufficient, a \"+\" should be good \nenough, or if you really want, \"::\". As the helper gets the complete \nURL, it can figure out how to proceed from here, without any need for \ncore Git to know how.\n\nCiao,\nDscho\n"},{"id":"122439","messageId":"alpine.LNX.2.00.0909041114440.28290@iabervon.org","threadId":"20839","inReplyTo":"fabb9a1e0909032229k5e6e2ed5mc11e8ff9c16dfcc0@mail.gmail.com","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-09-04T15:40:20Z","receivedAt":"2009-09-04T15:40:20Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 4 Sep 2009, Sverre Rabbelier wrote:\n\n> Heya,\n> \n> On Fri, Sep 4, 2009 at 04:13, Daniel Barkalow wrote:\n> > Instead of trying to make http://, https://, and ftp:// URLs\n> > indicative of some sort of pattern of transport helper usage, make\n> > them a special case which runs the \"curl\" helper, and leave the\n> > mechanism by which arbitrary helpers will be chosen entirely to future\n> > work.\n> \n> I'm sorry, I missed a few emails I think :(. Would you mind explaining\n> why we chose to special-case the curl helpers instead of the symlink\n> scheme?\n\nIt turns out that the method used to form URLs that use a helper doesn't \ngeneralize well to other cases, because it interferes with the ssh-style \nlocations. Instead, some different mechanism needs to be made up to handle \narbitrary handlers that git doesn't know about. Since we want to keep \nsupporting \"http://something\", that'll have to be a special case anyway, \nand so we might as well handle it by having git know what helpers to use \nfor things that we've always supported, and use a single descriptive name \nfor the helper that handles that collection of URLs.\n\nAs of this version, the idea is that there will be three ways helpers get \nselected:\n\n - git selects a helper based on the URL being something traditionally \n supported internally; that is, git recognizes the URL and knows what to \n run, if possible, to handle it\n\n - git uses the \"vcs\" option if it is set\n\n - something with the URL that we don't understand well enough yet to \n design, but which doesn't seem to be possible to fit in as a single \n rule with the first item.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"122451","messageId":"fabb9a1e0909041014h3b2789d7i90115ac69368d442@mail.gmail.com","threadId":"20839","inReplyTo":"alpine.LNX.2.00.0909041114440.28290@iabervon.org","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-09-04T17:14:53Z","receivedAt":"2009-09-04T17:14:53Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Sep 4, 2009 at 17:40, Daniel Barkalow wrote:\n> As of this version, the idea is that there will be three ways helpers get\n> selected:\n\nHow does this interact with wanting to support\n\"hg://example.org/example\" by adding 'git-remote-hg' to you path? Does\nit make that harder, or is it just not part of this series? I really\ndo think we should support that, and only resort to \"svn::\" or such if\nthe url is ambiguous (e.g., with a 'https://' prefix, etc).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"122452","messageId":"7vy6ouk4io.fsf@alter.siamese.dyndns.org","threadId":"20839","inReplyTo":"alpine.LNX.2.00.0909041114440.28290@iabervon.org","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-04T17:23:43Z","receivedAt":"2009-09-04T17:23:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> It turns out that the method used to form URLs that use a helper doesn't \n> generalize well to other cases, because it interferes with the ssh-style \n> locations. Instead, some different mechanism needs to be made up to handle \n> arbitrary handlers that git doesn't know about. Since we want to keep \n> supporting \"http://something\", that'll have to be a special case anyway, \n> and so we might as well handle it by having git know what helpers to use \n> for things that we've always supported, and use a single descriptive name \n> for the helper that handles that collection of URLs.\n>\n> As of this version, the idea is that there will be three ways helpers get \n> selected:\n>\n> - git selects a helper based on the URL being something traditionally \n> supported internally; that is, git recognizes the URL and knows what to \n> run, if possible, to handle it\n>\n> - git uses the \"vcs\" option if it is set\n>\n> - something with the URL that we don't understand well enough yet to \n> design, but which doesn't seem to be possible to fit in as a single \n> rule with the first item.\n\nThanks for a clear description.\n\nI do not see that there is much difference between the above description\nand what Dscho is advocating, and I do not see anything to get excited\nabout as Dscho seems to do. In his world, hg:// or any URL that begins\nwith :// wants to be a short-hand to name the helper, and the\nthird rule whose detail is unspecified in the above list could be\nsomething like:\n\n - With an explicit , i.e.\n\n \n\n tells the named helper git-remote- to interact with\n repository that it can find using . We do not interpret,\n nor guess from, what is, in this case.\n\n - When all else fails, and the URL looks like ://,\n we see if git-remote- is available and give it the whole\n string (including the ::// part).\n\nwhich means that what Dscho wants is already a subset of the future\ndirection planned for this series.\n\nAs to the \"curl\" indirection, if you consider the possiblity of someday\nadding the transparently backward compatible cgi based server with updated\nclients Gitney talked about, I am reasonably sure that we would want to\nhave a new helper, say http-cgi, and have interested people invoke it\nusing the \"more explicit\" escape hatch:\n\n $ git clone http-cgi::http://repo.or.cz/w/alt-git.git/\n\nwhile others can continue using the walker via a plain http://repo.or.cz/\nURL. When http-cgi helper proves to be successful and everybody's server\nupgrades, we might choose to swap the default, say in git 1.10.0 release,\nwhile leaving the door open for people to choose the old helper via an\nexplicit curl::http://repo.or.cz/ URL.\n\nIn short, from where I sit, I do not see much disagreement in the\nsemantics and in the future direction between what Dscho is saying (unless\nI again misunderstood what he said) and what this round wants to bring.\n\nThe only slight difference is that having an explicit excape hatch as the\nfoundation, that usually does not have to be spelled out but does allow\nyou to, keeps the concept cleaner, while keeping the usability of the end\nresult.\n"},{"id":"122454","messageId":"fabb9a1e0909041052qbbb5558w6da72b46969135f4@mail.gmail.com","threadId":"20839","inReplyTo":"7vy6ouk4io.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-09-04T17:52:38Z","receivedAt":"2009-09-04T17:52:38Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Sep 4, 2009 at 19:23, Junio C Hamano wrote:\n> In short, from where I sit, I do not see much disagreement in the\n> semantics and in the future direction between what Dscho is saying (unless\n> I again misunderstood what he said) and what this round wants to bring.\n\nI think Dscho's main worry matches what I asked about earlier, will we\nbe able to say \"hg://example.org\" or not.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"122455","messageId":"alpine.DEB.1.00.0909041930450.8306@pacific.mpi-cbg.de","threadId":"20839","inReplyTo":"7vy6ouk4io.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-09-04T18:02:25Z","receivedAt":"2009-09-04T18:02:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 4 Sep 2009, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > It turns out that the method used to form URLs that use a helper \n> > doesn't generalize well to other cases, because it interferes with the \n> > ssh-style locations. Instead, some different mechanism needs to be \n> > made up to handle arbitrary handlers that git doesn't know about. \n> > Since we want to keep supporting \"http://something\", that'll have to \n> > be a special case anyway, and so we might as well handle it by having \n> > git know what helpers to use for things that we've always supported, \n> > and use a single descriptive name for the helper that handles that \n> > collection of URLs.\n> >\n> > As of this version, the idea is that there will be three ways helpers \n> > get selected:\n> >\n> > - git selects a helper based on the URL being something traditionally \n> > supported internally; that is, git recognizes the URL and knows \n> > what to run, if possible, to handle it\n> >\n> > - git uses the \"vcs\" option if it is set\n> >\n> > - something with the URL that we don't understand well enough yet to \n> > design, but which doesn't seem to be possible to fit in as a single \n> > rule with the first item.\n> \n> Thanks for a clear description.\n> \n> I do not see that there is much difference between the above description\n> and what Dscho is advocating, and I do not see anything to get excited\n> about as Dscho seems to do.\n\nI mainly take exception at complicating things with a \"vcs\" config \nvariable.\n\nThe way you describe it, I like it, as I do not see any mention of said \nconfig variable there.\n\nIf you allow \"git clone \" for foreign vcs URLs, you do not need the \n\"vcs\" variable. If you require that variable, you cannot allow an easy \nclone, and you will earn my opposition.\n\nCiao,\nDscho\n"},{"id":"122463","messageId":"alpine.LNX.2.00.0909041429540.28290@iabervon.org","threadId":"20839","inReplyTo":"alpine.DEB.1.00.0909041930450.8306@pacific.mpi-cbg.de","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-09-04T19:05:03Z","receivedAt":"2009-09-04T19:05:03Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 4 Sep 2009, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Fri, 4 Sep 2009, Junio C Hamano wrote:\n> \n> > Daniel Barkalow writes:\n> > \n> > > It turns out that the method used to form URLs that use a helper \n> > > doesn't generalize well to other cases, because it interferes with the \n> > > ssh-style locations. Instead, some different mechanism needs to be \n> > > made up to handle arbitrary handlers that git doesn't know about. \n> > > Since we want to keep supporting \"http://something\", that'll have to \n> > > be a special case anyway, and so we might as well handle it by having \n> > > git know what helpers to use for things that we've always supported, \n> > > and use a single descriptive name for the helper that handles that \n> > > collection of URLs.\n> > >\n> > > As of this version, the idea is that there will be three ways helpers \n> > > get selected:\n> > >\n> > > - git selects a helper based on the URL being something traditionally \n> > > supported internally; that is, git recognizes the URL and knows \n> > > what to run, if possible, to handle it\n> > >\n> > > - git uses the \"vcs\" option if it is set\n> > >\n> > > - something with the URL that we don't understand well enough yet to \n> > > design, but which doesn't seem to be possible to fit in as a single \n> > > rule with the first item.\n> > \n> > Thanks for a clear description.\n> > \n> > I do not see that there is much difference between the above description\n> > and what Dscho is advocating, and I do not see anything to get excited\n> > about as Dscho seems to do.\n> \n> I mainly take exception at complicating things with a \"vcs\" config \n> variable.\n> \n> The way you describe it, I like it, as I do not see any mention of said \n> config variable there.\n> \n> If you allow \"git clone \" for foreign vcs URLs, you do not need the \n> \"vcs\" variable. If you require that variable, you cannot allow an easy \n> clone, and you will earn my opposition.\n\nSome foreign vcses, including the only one I ever personally use, do not \nhave URLs, and require a bunch of options and paths to specify a \nrepository. I don't want to have to use:\n\n\turl = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...\n\n(actually, I don't even know what the normal thing is for a URL for \nsomething that's split between multiple locations, or how URLs handle \n\"servers\" that are arbitrary commands including options which make a \nconnection to the server)\n\nFor cases where the foreign vcs has something to put in the \"url\" spot, \nyou don't need to set \"vcs\". In fact, you are only allowed to set one or \nthe other of \"vcs\" and \"url\" with my current version. What you're \ninterested in is explicitly left for later, when we have a prototype \nhelper for such a foreign vcs and can try it out with potential users.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"122464","messageId":"fabb9a1e0909041235x74a3b9b4gf65e650ca0d00831@mail.gmail.com","threadId":"20839","inReplyTo":"alpine.LNX.2.00.0909041429540.28290@iabervon.org","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-09-04T19:35:21Z","receivedAt":"2009-09-04T19:35:21Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Sep 4, 2009 at 21:05, Daniel Barkalow wrote:\n> Some foreign vcses, including the only one I ever personally use, do not\n> have URLs, and require a bunch of options and paths to specify a\n> repository. I don't want to have to use:\n>\n>        url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...\n\nBtw, doesn't p4 have these config files that you can download that\ncontain the configuration? In that case\n'p4://example.org/p4/main-development.configfile' would be very\nconvenient.\n\nRegardless, I do think there should be some way to specify all this\noutside of the url, but to me that's secondary. I think the primary\nusecase is/should be cloning from some url in the form of\n'hg://example.org/foo', rather than 'http://example.org/some-hg-repo'\nor 'p4://.......', since those are both exceptions (the former being\nan ambiguous url, and the latter being a non-url). Now I do understand\nif you don't want to spend your time on implementing the specialized\nurl support since it doesn't scratch your itch, but at least your\nseries shouldn't impend supporting that in the near future.\n\n> For cases where the foreign vcs has something to put in the \"url\" spot,\n> you don't need to set \"vcs\". In fact, you are only allowed to set one or\n> the other of \"vcs\" and \"url\" with my current version. What you're\n> interested in is explicitly left for later, when we have a prototype\n> helper for such a foreign vcs and can try it out with potential users.\n\nI need to hurry up and get working on that hg implementation then :).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"122468","messageId":"alpine.LNX.2.00.0909041546030.28290@iabervon.org","threadId":"20839","inReplyTo":"fabb9a1e0909041235x74a3b9b4gf65e650ca0d00831@mail.gmail.com","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-09-04T20:10:44Z","receivedAt":"2009-09-04T20:10:44Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 4 Sep 2009, Sverre Rabbelier wrote:\n\n> Heya,\n> \n> On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow wrote:\n> > Some foreign vcses, including the only one I ever personally use, do not\n> > have URLs, and require a bunch of options and paths to specify a\n> > repository. I don't want to have to use:\n> >\n> >        url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...\n> \n> Btw, doesn't p4 have these config files that you can download that\n> contain the configuration? In that case\n> 'p4://example.org/p4/main-development.configfile' would be very\n> convenient.\n\nThe only thing I know of which you might be thinking of is \"client \nspecifications\", which are like git superprojects. They're almost certain \nto only specify one of the multiple locations that you want to have in the \nsame repository; the multiple locations are the paths you want to treat \nas branches, and the client picks one branch of each project and places \nit in some non-branch-specific location relative to other projects. (Of \ncourse, someday I might want to support importing a client specification \nas a git project with submodules, but it's got the same issues as \nsvn::externals without revision specifications seems to).\n\nIn any case, p4 doesn't have any easy generic way to specify how to \ncontact the server, and doesn't have anything client-side.\n\n> Regardless, I do think there should be some way to specify all this\n> outside of the url, but to me that's secondary. I think the primary\n> usecase is/should be cloning from some url in the form of\n> 'hg://example.org/foo', rather than 'http://example.org/some-hg-repo'\n> or 'p4://.......', since those are both exceptions (the former being\n> an ambiguous url, and the latter being a non-url). Now I do understand\n> if you don't want to spend your time on implementing the specialized\n> url support since it doesn't scratch your itch, but at least your\n> series shouldn't impend supporting that in the near future.\n\nI'm pretty sure that this series makes your primary usecase slightly \nsimpler to support, because it no longer is expected to handle the \nambiguous \"http://\" class of URLs.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"122471","messageId":"alpine.DEB.1.00.0909042305390.8306@pacific.mpi-cbg.de","threadId":"20839","inReplyTo":"fabb9a1e0909041235x74a3b9b4gf65e650ca0d00831@mail.gmail.com","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-09-04T21:08:16Z","receivedAt":"2009-09-04T21:08:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 4 Sep 2009, Sverre Rabbelier wrote:\n\n> On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow \n> wrote:\n> > Some foreign vcses, including the only one I ever personally use, do \n> > not have URLs, and require a bunch of options and paths to specify a \n> > repository. I don't want to have to use:\n> >\n> >        url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...\n> \n> Btw, doesn't p4 have these config files that you can download that \n> contain the configuration? In that case \n> 'p4://example.org/p4/main-development.configfile' would be very \n> convenient.\n\nIf that's how p4 users initialize their working directories, then that is \nthe way to go.\n\nAnd I cannot start to believe that the complicated way you described is \nthe common way to initialize p4 working directories, as that would tempt \nthe intelligence/enthusiasm of the average programmer.\n\n> > For cases where the foreign vcs has something to put in the \"url\" \n> > spot, you don't need to set \"vcs\". In fact, you are only allowed to \n> > set one or the other of \"vcs\" and \"url\" with my current version. What \n> > you're interested in is explicitly left for later, when we have a \n> > prototype helper for such a foreign vcs and can try it out with \n> > potential users.\n> \n> I need to hurry up and get working on that hg implementation then :).\n\nIndeed you do. If only to prove that _this_ and the likes are something \nto optimize for, not some obscure vcs config variable that only introduces \na little-exercized code path that's _prone_ to break and does not help \nanybody.\n\nCiao,\nDscho\n"},{"id":"122472","messageId":"alpine.LNX.2.00.0909041750390.28290@iabervon.org","threadId":"20839","inReplyTo":"alpine.DEB.1.00.0909042305390.8306@pacific.mpi-cbg.de","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-09-04T22:18:55Z","receivedAt":"2009-09-04T22:18:55Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 4 Sep 2009, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Fri, 4 Sep 2009, Sverre Rabbelier wrote:\n> \n> > On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow \n> > wrote:\n> > > Some foreign vcses, including the only one I ever personally use, do \n> > > not have URLs, and require a bunch of options and paths to specify a \n> > > repository. I don't want to have to use:\n> > >\n> > >        url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...\n> > \n> > Btw, doesn't p4 have these config files that you can download that \n> > contain the configuration? In that case \n> > 'p4://example.org/p4/main-development.configfile' would be very \n> > convenient.\n> \n> If that's how p4 users initialize their working directories, then that is \n> the way to go.\n> \n> And I cannot start to believe that the complicated way you described is \n> the common way to initialize p4 working directories, as that would tempt \n> the intelligence/enthusiasm of the average programmer.\n\nPerforce is probably the single most popular system for git to import from \nbecause it is such a monumental pain to use for anything at all that it's \neasier to learn git, write a git importer, and use your git importer than \nit is to actually use Perforce directly.\n\nOf course, it's not really beyond the average programmer to get a p4 \nworking directory, because whoever is running the server will have \nprovided a file to copy and instructions on setting an environment \nvariable. They don't know what the magic formula means; they just use it. \nAnd they only work on one branch until that branch is done with,\nand then they throw away that working directory, get a new working \ndirectory, and never look at the other branch's history again (and \ncertainly never track anything across branches). Also, they have p4 \nexperts who deal with merging branches so that stuff doesn't get lost when \nmoving to a new branch. And the experts have scripts built into the \nrelease process that attempt to insure that things don't get lost. The \nreason that my helper can't have a single location for a repository is \nthat the branches of a single project are strewn randomly about the \nnamespace, and a proper git import needs to know what to stitch into a \nsingle repository.\n\nFor the matter of where the server is, Perforce supports just having a \n\"server:port\" value, but if the organization uses this, there's no \nauthentication of users possible. Instead, organizations set up an ad hoc \ncollection of ssh proxies and give people a string which is the command to \ngo through those proxies, because Perforce only knows how to use rsh or a \ncommand you provide that acts like rsh.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"122473","messageId":"alpine.DEB.1.00.0909050023240.8306@pacific.mpi-cbg.de","threadId":"20839","inReplyTo":"alpine.LNX.2.00.0909041750390.28290@iabervon.org","subject":"Re: [PATCH 1/8] Make the \"traditionally-supported\" URLs a special case","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-09-04T22:36:40Z","receivedAt":"2009-09-04T22:36:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 4 Sep 2009, Daniel Barkalow wrote:\n\n> On Fri, 4 Sep 2009, Johannes Schindelin wrote:\n> \n> > Hi,\n> > \n> > On Fri, 4 Sep 2009, Sverre Rabbelier wrote:\n> > \n> > > On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow \n> > > wrote:\n> > > > Some foreign vcses, including the only one I ever personally use, do \n> > > > not have URLs, and require a bunch of options and paths to specify a \n> > > > repository. I don't want to have to use:\n> > > >\n> > > >        url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...\n> > > \n> > > Btw, doesn't p4 have these config files that you can download that \n> > > contain the configuration? In that case \n> > > 'p4://example.org/p4/main-development.configfile' would be very \n> > > convenient.\n> > \n> > If that's how p4 users initialize their working directories, then that is \n> > the way to go.\n> > \n> > And I cannot start to believe that the complicated way you described is \n> > the common way to initialize p4 working directories, as that would tempt \n> > the intelligence/enthusiasm of the average programmer.\n> \n> Perforce is probably the single most popular system for git to import \n> from because it is such a monumental pain to use for anything at all \n> that it's easier to learn git, write a git importer, and use your git \n> importer than it is to actually use Perforce directly.\n> \n> Of course, it's not really beyond the average programmer to get a p4 \n> working directory, because whoever is running the server will have > \n> provided a file to copy and instructions on setting an environment \n> variable.\n\nThat is what we need to optimize for, then.\n\n> They don't know what the magic formula means; they just use it. And they \n> only work on one branch until that branch is done with, and then they \n> throw away that working directory, get a new working directory, and \n> never look at the other branch's history again (and certainly never \n> track anything across branches). Also, they have p4 experts who deal \n> with merging branches so that stuff doesn't get lost when moving to a \n> new branch. And the experts have scripts built into the release process \n> that attempt to insure that things don't get lost. The reason that my \n> helper can't have a single location for a repository is that the \n> branches of a single project are strewn randomly about the namespace, \n> and a proper git import needs to know what to stitch into a single \n> repository.\n\nAnd why not having the different branches which are strewn randomly about \nthe namespace as separate remotes for a Git repository? After all, the \naverage p4 user will be wanting to work on _one_ branch, as you so aptly \ndescribed.\n\n> For the matter of where the server is, Perforce supports just having a \n> \"server:port\" value, but if the organization uses this, there's no \n> authentication of users possible. Instead, organizations set up an ad \n> hoc collection of ssh proxies and give people a string which is the \n> command to go through those proxies, because Perforce only knows how to \n> use rsh or a command you provide that acts like rsh.\n\nThat explains a tiny part of the long path you provided, but certainly not \nall (I am especially curious what /bin/true thinks it's doing in that \nURL).\n\nIf what you said about ssh is true, then it should be the same type of \ninvocation everywhere, and it should certainly be very easy to provide a \nshortcut for that URL; no need for the _user_ (who could not care less how \nssh happens to be called) to remember.\n\nSomething like \"git clone p4::ssh://p4ssh@projects/foo/bar-1.0/...\" should \nbecome a very easy and intuitive way for the average programmer to clone a \np4 branch into a Git repository.\n\nShould the developer ever need to work with another branch of the same \nproject, very easy:\n\n\t$ git remote add -f bar-1.1 p4::ssh://p4ssh@projects/foo/bar-1.1/...\n\t$ git checkout -b my-1.1 bar-1.1/master\n\nNow, I am not married to having more than one remote for multiple \nbranches, but there is _no_ reason why this has to be done at clone time, \nif the average p4 user does not do that either. You can always teach \ngit-remote-p4 to behave sensibly and ask the user to\n\n\t$ git config --add remote.origin.fetch \\\n\t\t+/foo/bar-1.1:refs/remotes/origin/bar-1.1\n\nNote, these are two alternative suggestions. I am not trying to decide \nwhat is better here, but I am convinced that both options are more \nintuitive than the \"vcs\" variable.\n\nCiao,\nDscho\n"}]}