Thanks a lot Peff. This cleared a lot of things. Would it be okay if I cite some parts of this conversation on my personal blog? On Fri, Jun 17, 2016 at 8:31 PM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Jun 17, 2016 at 08:05:47PM +0530, Saksham Saxena wrote: > >> > ..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. > >> > You should be able to clone, fetch, or push wiki repositories using any >> > of the normal protocols. So: >> > >> > git@xxxxxxxxxx: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 Thanks and Regards Saksham Saxena -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html