From: Daniel Barkalow Date: Tue, 03 May 2005 02:56:37 GMT Subject: Re: More problems... Message-ID: In-Reply-To: <20050503014816.GQ20818@pasky.ji.cz> On Tue, 3 May 2005, Petr Baudis wrote: > BTW, I've just committed support for pulling from remote repositories > over the HTTP and SSH protocols (http://your.git/repo, > git+ssh://root@git.nasa.gov/srv/git/mars) (note that I was unable to > test the SSH stuff properly now; success reports or patches welcome). > Also, the local hardlinking access is now done over git-local-pull, > therefore the cp errors should go away now. Before you get too far with the SSH version, I have some protocol changes which (1) allow transmission of things other than objects; (2) allow the pushing side to report that it doesn't have something without killing the connection; (3) send refs. (1) and (2) are needed to make the protocol extensible; (3) takes advantage of (1) to make it possible to maintain a remote repository without doing anything other than rpush to it. This goes with my patches from the weekend to enable git-*-pull to transfer refs/ files in the same process. > I'm not yet decided whether locations like > > kernel.org:/pub/scm/cogito/cogito.git > > should invoke rsync, rpull, throw an error or print a fortune cookie. Probably not rpull, which requires a login, at least not unless the others fail. I think that http-pull is going to be nicer in the long run than rsync, since the remote repository could have a bunch of mingled heads and http-pull will get exclusively the interesting stuff. If you're trying to push, then rpush, since that's the only push. Personally, I've been using http://... for http-pull, rsync://... for rsync, and //... for rpull/rpush (which is somewhat justified wrt the URI standard for using the program's default method). -Daniel *This .sig left intentionally blank*