On Tue, Dec 01, 2009 at 02:15:17PM -0500, Daniel Barkalow wrote: > On Tue, 1 Dec 2009, Ilari Liusvaara wrote: > > > HTTP, HTTPS and FTP are no longer special to transport code. Also > > add support for FTPS (curl supports it so it is easy). > > We've been through this extensively, and settled on having a special case > for URLs that specify a pure location. That is, the distinction between > http and ftp is at the level of how you get to the content for that > location, not what you do to interact with it. (Even with webdav or the > git-specific smart server support, we use the same detection method on all > locations, and ftp simply never has the possibility of having these > features detected.) Currently the only thing about http:// and co git main executable knows is to pass them to curl remote helper (and print error if compiled with NO_CURL, possibly causing problems with version desync). Git main executable does not know any difference between say http:// and ftp:// (the remote helper must obiviously know the difference, but remote helper is not part of git main executable). > It would be fine to add "ftps" to the list of URL schemes that indicate a > pure location, except that it's plausible that ftps supports writing, but > obviously not by webdav, which is what the push support via curl will > attempt, so it's more likely to be confusing than helpful. remote-curl.c code doesn't seem to do anything stupid with ftps:// that it wouldn't try with ftp://, and trying to push counts as "stupid" here (and remember that many FTP servers do allow unencrypted uploads, especially with authentication and CURL can AFAIK handle that). -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