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

Git repositories have become indispensable resources for citing parts of a development history with links. However, the format of git remote entries is not always distinguishable from other types of citation -- for example a git reference vs. a plain URL.

Rather than rely on context to tell me that `https://github.com/git/git` refers to a git repository which I could clone with git over https, it would be nice to use a url like `git+https://github.com/git/git` or even `git+https://github.com/git/git?commit=d0e8084c65cbf949038ae4cc344ac2c2efd77415` to unambiguously specify that the type of data and its method of access are native to git.

This issue is extremely important for version control systems which build dependency lists from git, e.g. https://pip.pypa.io/en/stable/topics/vcs-support/

That project lists several invented URL schemes (all beginning with git+) and assigning special reserved characters (https://datatracker.ietf.org/doc/html/rfc3986#section-2.2) git+https://git.example.com/MyProject.git@master git+https://git.example.com/MyProject.git@v1.0 git+https://git.example.com/MyProject.git@da39a3ee5e6b4b0d3255bfef95601890afd80709 git+https://git.example.com/MyProject.git@refs/pull/123/head

It would be helpful for the git project itself to define its own URL scheme to codify these use cases and, possibly in addition, provide a standard way to reference within git repositories.

For reference, some of the ways URLs are already used/defined within
git are documented here:
- https://github.com/git/git/blob/d0e8084c65cbf949038ae4cc344ac2c2efd77415/connect.c#L107
  (alternately, using gitweb syntax not actually available on github,
https://github.com/git/git.git/blob/d0e8084c65cbf949038ae4cc344ac2c2efd77415:/git/connect.c)
- https://mirrors.edge.kernel.org/pub/software/scm/git/docs/gitremote-helpers.html
- https://git-scm.com/docs/git-http-backend
- https://git-scm.com/docs/gitweb

Currently, a comment in connect.c notes "git+" schemes were deprecated. However, I would argue that at a minimum, these "git+" schemes should be a supported and documented feature of git. Also, something has to be fixed (or better communicated) about URLs of the form "git@github.com:user/project.git" These are implicitly treated as "git+ssh://git@github.com/user/project.git", but the use of ":" is confusing from the perspective of translating between these two forms.

In addition, the use of paths, queries, and fragments should be
considered to allow (IMHO) at least 3 distinct uses:
1. naming commit-ish objects (and potentially metadata like author and
parents within the commit)
2. naming tree-ish objects and paths within them
3. naming blobs (and potentially fragment identifiers like lines or
HTML tags within those blobs)

These further refinements don't have to be supported by any special functions within git. However, their existence may influence git data structures and api-s in the future.

The last discussion I can find of this issue on the git mailing list (https://lore.kernel.org/git/C9Y2DPYH4XO1.3KFD8LT770P2@taiga) indicates that defining conventions like these within git's documentation would be a good place to start. On a separate thread, I will send a draft "git+" URI naming scheme for discussion and eventual submission to IANA (https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml).

~ David M. Rogers