Unset or empty remote URL behavior does not match with git CLI

[ehuss]

The behavior when a remote's URL is either the empty string, or not set, does not match with the git CLI. If the url is empty or not set, then the CLI uses the remote's name as the URL. I think this is implemented here if you are curious.

Currently, when the url is the empty string, git_remote_url returns NULL. At a minimum, I think it would be good to document that.
If the url is not set, then you get an error loading the remote.

For example, if you have this remote config:

[remote "foo"]
	url =
	fetch = +refs/heads/*:refs/remotes/foo/*

then git_remote_url will return NULL for that remote, whereas git remote get-url foo will print foo, and git fetch foo is also able to fetch from foo if it is a relative path.

[ethomson]

Well that's just fucking horrifying. But thanks for the report.

[ethomson]

Well, this is going to be fun. My git (v2.45.3) doesn't quite behave this way.

[remote "foo"]
	url =
	fetch = +refs/heads/*:refs/remotes/foo/*

gives no remote:

$ git remote get-url foo

but when the url key doesn't exist at all, then it does use the remote name:

[remote "foo"]
    fetch = +refs/heads/*:refs/remotes/foo/*

$ git remote get-url foo
foo

[ehuss]

Oh weird! Sorry, I should have noted the git version I was running (2.47.0). I believe this changed in 2.46.0 via git/git@9badf97.

I can't really tell if this is intentional behavior.

BTW, I noticed your GitHub ISSUE_TEMPLATE isn't working. I dunno if being a file was some legacy thing that doesn't work with the new GitHub Issues, but it looks like they want that to be a directory now with files inside it.

[ethomson]

Interesting! That's helpful. I... can't tell either, but as I often bemoan, we try to be bug-for-bug compatible.