Re: URL rewrite in local config unable to override global config rule

From: Jeff King <peff@peff.net>
Date: Jun 17, 2016, 15:01 UTC
Message-ID: <20160617150137.GA9197@sigill.intra.peff.net>
In-Reply-To: <CABYP2JZ5nNHh_cRkgpRMkn7Qfs4zAjy+wfaputJ0CvZ-M4FW6w@mail.gmail.com>

On Fri, Jun 17, 2016 at 08:05:47PM +0530, Saksham Saxena wrote:

Show 7 quoted lines

> > ..even if I have an existing "url.git://.insteadOf=https://". But I
> > could believe that having other config confuses things. The
> > url-rewriting is not "last one wins", but rather that we try all of
> >
> > > them, and the longest match wins.
> 
> Longest? Could you elaborate please?

The one that matches the longest number of characters. So "https://example.com" is a preferred match over "https://".

I don't think that's what's going on here, though.

> Here you go (https://gist.github.com/sakshamsaxena/a1cee9c39ddc127ae659e92d02d58f0b).
> The commands are run in that sequence.

OK, so you have:

  url.git://.insteadof=https://

in your initial config, to convert https URLs to git.

Later you add:

  url.https://.insteadof=git://

to do the opposite.

The URL in your config uses http:

  remote.origin.url=https://github.com/sakshamsaxena/sails-hook-jbvcs.wiki.git

And when you push, this gets converted to "git://".

I think this is the expected behavior, due to the first insteadOf, which converts https to git. Both rules are "active", in the sense that the later one does not replace the former; together they make a list of rules to try applying.

Git doesn't recursively apply insteadOf transformations. So the "convert https to git" rule triggers, and we stop. The "convert git to https" one doesn't trigger initially (because we are already https). And if we were to apply rules recursively in this case, it would loop infinitely.

So I this is all operating as intended. And what you really want is a way to say "erase any earlier rewrite rules; I do not want them applied in this repository". There's currently not any way to do that.

For other "multi-valued configs" like this one (i.e., ones that form a list rather than overriding earlier values), we have started using the convention that assigning the empty value resets the list. But this particular config key has not learned that trick yet, so it would require a patch to git.

Show 10 quoted lines

> > You should be able to clone, fetch, or push wiki repositories using any
> > of the normal protocols. So:
> >
> >   git@github.com:username/repo.wiki.git
> >
> > should work. Likewise, git:// will work if the repository is public, but
> >
> > > you cannot push over it.
> 
> True. Can't push over git:// and that's why I'm limited to https://

You can over ssh, though (which I thought you said earlier was your preferred protocol).

-Peff