[pacman-dev] The great VCS packages overhaul of 2015

Dan McGee dpmcgee at gmail.com
Tue Mar 13 07:53:13 EDT 2012


On Tue, Mar 13, 2012 at 7:41 AM, Florian Pritz <bluewind at xinu.at> wrote:
> 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
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


More information about the pacman-dev mailing list