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

From: Jeff King <peff@peff.net>
Date: Aug 12, 2009, 07:45 UTC
Message-ID: <20090812074521.GD15152@coredump.intra.peff.net>
In-Reply-To: <alpine.DEB.1.00.0908120128120.8306@pacific.mpi-cbg.de>

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

Show 5 quoted lines

> > 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.

Show 10 quoted lines

> 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