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

Jeff King [off-list ref] writes:

So you definitely need to "somehow" know that a URL is meant to be used
with Git. And that makes me somewhat sympathetic to your request.

Nicely summarized.  I am also sympathetic to the cause, but I do not
see upside in tucking the information to the URL syntax.  Even if we
limit ourselves to the CI context, I do not see how the repository
location alone is sufficient (e.g. "build the tip of this branch of
that repository every time it gets updated" already needs more than
the repository location).

The downsides I see are:

  - one of the advantages of straight http:// URLs is that they can
    accessed by multiple tools. Most "forge" tools let you use the same
    URL both for getting a human-readable page in a browser, as well as
    accessing the repository with the Git CLI. I'd hate to see https+git
    URLs become common, because they add friction there (though simply
    supporting them at all gives people the choice of whether to use
    them).

  - I'm also sympathetic to brian's point that there's a wider
    ecosystem. It's not just "git" that needs to learn them. It's jgit,
    and libgit2, and many tools that work with git remotes.

Yup.

The status quo is similarly frustrating. We have no choice but to allow
these strange unofficial +git URLs to proliferate among package managers
and build systems. It has already caused confusion with users, and it
can only cause more the longer it remains unaddressed upstream.

There are two options:

1. We make the change, users are confused for a while, and software has
   to be updated, but the confusion gradually diminishes over time as
   the ecosystem adjusts and people learn the change.
2. We don't make the change, and the inconsistency continues to require
   special cases in new tools, with no central organization for keeping
   them consistent from one to the next, and users will continue to stub
   their toe on it indefinitely.