On 13.03.2012 04:58, Allan McRae wrote:
1) URL: There were previous patches to the mailing list that never really got finished, but I think we were fairly happy with this syntax:
source=(git://projects.archlinux.org/pacman.git) source=(git@@http://projects.archlinux.org/git/pacman.git)
Does it make any sense to allow the "::" syntax here? i.e. source=(git@@dirname::http://projects.archlinux.org/git/pacman.git)
If you want to allow multiple sources of the same project, please don't clone them into multiple directories. You'd just duplicate all objects they share (which could be many).
Better cd into the one you already have and simply add a new remote. I don't think this was the case anyone was talking about here. More
On Tue, Mar 13, 2012 at 7:41 AM, Florian Pritz <bluewind@xinu.at> wrote: like sources from: git://code.example.com/project.git git://code.example.com/project-extras.git
I don't like the @@ and :: syntax. Maybe "git://remotename//http://projects.archlinux.org/git/pacman.git"? That way we can simply look for "git://" and also easily figure out if there is a remote name or not. "//" should also be a safe delimiter because in the URL it would be collapsed to "/" anyway. Heck no, minus -1000. We are **not** reinventing a URL syntax. This is confusing, misleading, and awful. Look at this: git://remotename//git://projects.archlinux.org/pacman.git
I don't even know what remotename is (but if that can contain a '/', my eyes will really bleed). The double URL specifier (using the same protocol twice!!) is likely not allowable or recommended by http://tools.ietf.org/html/rfc3986. If you are trying to stick with URI/URL format, I'd much rather see git+http:// in this case, which is a lot like the 'svn+ssh://' protocol you can use, etc. And then use fragment identifiers perhaps (RFC 3986, 3.5, '#branchname') to identify the branch name. -Dan