Re: More problems...
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- May 3, 2005, 02:56 UTC
- Message-ID
- <Pine.LNX.4.21.0505022240040.30848-100000@iabervon.org>
- In-Reply-To
- <20050503014816.GQ20818@pasky.ji.cz>
On Tue, 3 May 2005, Petr Baudis wrote:
Show 6 quoted lines
> 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.
Show 5 quoted lines
> 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*