Re: Regarding the depreciation of ssh+git/git+ssh protocols

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Nieder wrote:
> This is useful context.  What URL forms does this package manager
> support (e.g., do you have a link to its documentation)?  What would
> the effect be for the package manager and its users if Git started
> supporting a git+https:// synonym for https://?

Here are two more examples:

- pip: https://pip.pypa.io/en/latest/cli/pip_install/#git
- SPDX: https://spdx.github.io/spdx-spec/3-package-information/#37-package-download-location

The common thread is that systems need a way to uniquely identify a git
repository or some object therein. I believe this means some combination
of:

- VCS type (git)
- Transport location (e.g. https://github.com/git/git)
- Ref (e.g. master)
- Resolved commit ID (e.g. 48bf2fa8bad054d66bd79c6ba903c89c704201f7)
- Path (e.g. contrib/diff-highlight)
- (possibly) Clone depth

As Drew has said, the current state of affairs is that, lacking a
standard, multiple systems are all inventing incompatible schemes using
the `git+https` name. This is not a good situation because the "URI" is
no longer "unique". Given such a URI in isolation, one cannot know how
to parse it.

It's not clear to me that git itself needs to support this scheme. It
would go a long way for git to simply recommend a particular scheme so
that all these systems can use a common format. (We could register that
with IANA.) The pip format seems to be the closest, but it doesn't
support both ref AND resolved commit ID, and it is currently specific to
pip (`egg=` could be replaced with `path=`).

Best,
Mark



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux