On Wed, Dec 02, 2009 at 06:39:19PM +0100, Johannes Schindelin wrote: > > This is definitely a good direction, and it would be even better if the > absence of the remote helper was also handled gracefully. Just think > about a (as of now fictious) git-remote-http.rpm relying on git-core.rpm > and libcurl.rpm. If you do not want to access http:// URLs, you can > install just git-core. Once you encounter an http:// URL you need to > access, you install git-remote-http. Keeping git-core. (I like to call > this setup "modular".) There are some rather unfortunate details relating to this. Main git executable currently has no good way to discover what went wrong with remote helper execution that fails before reaching capabilities exchange. It would be ideal if executions failing due to ENOENT would be reported as remote helper not existing, other exec errors reported as failed execution, fatal signals as remote helper crashing and other exits rely on remote helper reporting the problem. Unfortunately, this can't be done without breaking remote helper interface, either by requiring initial response from helper or requiring helpers not to explicitly fail due to bad parameters before reaching capabilities exchange, since one can't know if execution was successuful without seeing at least one incoming line. IIRC, current versions print some rather funky error if you try to use nonexistent helper: 'remote-foo is not git command' or some such. > Of course, I never understood why the backend should know the > implementation detail that it is based on cURL, so it would be even more > modular (at least by my definition) if there was no hard-coded mapping > (Sverre -- Cc'ed -- seemed to like URLs of the form "svn::http://..."; and > "cvs::pserver..." to trigger looking for a remote helper explicitely). I > find the compiled-in mapping rather limiting. That syntax is rather nice for handling foregin VCSes that may have URL forms that overlap with native ones. But it sure isn't nice for those remote helpers that implement git native transports (remote-curl is already a precedent on doing that). The API is already general enough to do both: Git native transports (currently dumb only without lots of effort, which this patchset is about) and foregin VCS bridges. -Ilari -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html