Also re: your PS - as you say, I'm sure it's more than a one-line change. I think it's a nice idea, though, as long as the configuration parsing doesn't get super complex as a result

I think I did look but couldn't see any existing documentation for domain and api_domain so thought maybe just the changelog would suffice, but maybe I missed it?

Also re: your PS - as you say, I'm sure it's more than a one-line change. I think it's a nice idea, though, as long as the configuration parsing doesn't get super complex as a result

Struck me there's a simpler (almost 1 line) approach: lukester1975@907840f

That said I don't think it's correct if the http access is via a subpath.

E.g. remote_url: ssh://gitea@my.server/org/repo-name
http url: https://my.server/gitea/org/repo-name

No way to infer that /gitea subpath component of the http path. But then the existing config option is available...

If you think this is a non-starter I'll see if I can find time to dig out the url from pyproject.toml.

Thanks

You're right, the options should be under the remote table but aren't yet.

Was thinking through the relative tradeoff between being simple and explicit (maybe causing duplication) and convenience having things auto-detected.
Could be sensible to do the following:
Try to derive api_domain from domain using some sensible defaults, if the config option is missing - those would be api.{domain} for GitHub, {domain}/api/v4 for Gitlab and {domain}/api/v1 for Gitea. In addition, we could try to detect domain from the following locations in order:

1. the remote.domain config option
2. git config --get remote.{name}.url, where {name} is the remote.name config option
3. project.urls.repository

That way we'd have a sensible set of locations and defaults, but we're somewhat consistent in how things are detected and when you have to specify things. Not suggesting all that has to go into a PR here, but keen to hear what you think 🙂

Probably put 3 before 2 due to the ssh/https issue and subpaths?