Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs

[Jeff King <peff@peff.net>]

On Wed, Aug 12, 2009 at 01:53:38AM +0200, Johannes Schindelin wrote:

> > It is not actually that unreasonable. I have remotes which point to:
> > 
> >   vcs:git/foo.git
> 
> That is still not "svn".

No, but you snipped the part where I explain how that leads me to
believe "svn" is plausible. Remember that you and I are just a
representative sample of a much larger userbase.

There is also a related question: should the the meaning of the URL rely
purely on _syntax_, or must we understand the _semantics_ of the
individual tokens? That is, given $X:$Y, does that syntactically mean
that $X _must_ be a remote helper, or must I understand what helpers git
knows about to know what it is?

I tend to think purely syntactic systems are more robust and easier to
understand. The downside is that it's less DWIM, which can often mean
more typing.

> If _I_ were to judge whether to make it convenient for computer-savvy 
> people like you who would have _no_ problem diagnosing the problem (_if_ 
> they have the problem, having edited .ssh/config themselves!), who would 
> curse briefly, and then go on fixing the problem, or in the alternative 
> make it convenient for people who do not know their way around .ssh/config 
> as well as you (and who happen to make up the _vast_ majority of Git users 
> by now [*1*]), and who would really prefer to have an easy way to clone 
> "foreign" repositories, I have _no_ problem deciding which way to go.
> 
> So I'm a bastard.  Big news.  But I'm a pragmatic one.

You didn't quote the part of my email about how ssh:// sucks. It is not
just about having my config break, figuring it out, and fixing it. You
are losing a useful construct that I might be using on the command line.

That being said, I am not 100% opposed to the proposal. I just think it
is worth considering this breakage as a downside, and considering

  1. Is there some other syntax that _doesn't_ have this breakage
     but that similarly helps the "vast majority of Git users".

  2. Should such a breakage follow a deprecation schedule, and if so,
     what schedule?

-Peff